Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

PyPi should warn when the package and developer are new.


Even Firefox and Chrome's extension "stores" don't get this right. In either, a once trusted extension can be sold to a malicious company who then pushes new updates which automatically get downloaded by Firefox and Chrome by default, with no warning. Quite possibly without Mozilla and Google having any way of knowing it happened at all.

One way to address this is to move to a traditional "debian" style system, where packages are people affiliated with / known by Debian/Mozilla/Google, and specifically aren't the developers of the software themselves. The software is written by Developer X, but is then packaged and distributed by Packager Y, who ideally has no commercial affiliation with Developer X. If Developer X sells out to Malware Corp Z, end users can hope that Packager Y isn't part of that deal and prevents the malware from being packaged and distributed. This still isn't bullet-proof, but it's a lot better.


Yeah a time/activity based trust system like thepiratebay uses could be helpful.

Also devs should get into the habit of providing sha256 hashes on offical channels (i.e., github readme) so users can validate (if its possible to validate a pkg before executing malicious code in the python ecosystem, I'm not sure how that'd work).


Doesn't pip's hash checking mode solve this issue? Freeze your requirements with hashes. Pypi already provides hashes for sdists and wheels. See https://pip.pypa.io/en/stable/topics/secure-installs/#hash-c...

If we are talking typos or other human errors, guess we could only warn people that there are other package with similar name available. Can't predict what people have in mind when they make a typo.


It definitely does help. We've seen malicious actors introduce "bad things" into legitimate packages [1]. So hashes help identify what you got, but doesn't necessarily prevent you from getting something you didn't intend.

[1] https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22...


> Also devs should get into the habit of providing sha256 hashes on offical channels (i.e., github readme) so users can validate (if its possible to validate a pkg before executing malicious code in the python ecosystem, I'm not sure how that'd work).

I would think the easy solution is to publish a public signing key per-person or per-project, and then sign individual files with that. So, GPG.


> Yeah a time/activity based trust system like thepiratebay uses could be helpful.

This is an excellent idea. Authors are something we are digging into heavily as part of an ongoing effort to improve trust in the open source ecosystem.


Yeah, an onboarding process build on trust and time-delay would be nice.


Totally agree. There should be a 30 day pe




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: