4 ms·

PyPi should warn when the package and developer are new.

prox 4y ago
Yeah, an onboarding process build on trust and time-delay would be nice.
stemlord 4y ago
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).
- yjftsjthsd-h 4y ago
  > 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.
- louislang 4y ago
  > 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.
- kroolik 4y ago
  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-checking-mode 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.
  - louislang 4y ago
    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/malware-discovered-popular-npm-package-ua-parser-js https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22...
MichaelCollins 4y ago
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.
pkrumins 4y ago
Totally agree. There should be a 30 day pe

prox 4y ago

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

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).

yjftsjthsd-h 4y ago
> 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.
louislang 4y ago
> 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.
kroolik 4y ago
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-checking-mode 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.
- louislang 4y ago
  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/malware-discovered-popular-npm-package-ua-parser-js https://www.cisa.gov/uscert/ncas/current-activity/2021/10/22...

MichaelCollins 4y ago

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.

pkrumins 4y ago

Totally agree. There should be a 30 day pe