4 ms·

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons.

by zzzeek 4y ago

josephwegner 4y ago
Yes, this lines up with the "Critical Project" concept that has been floating around in the past year. It is... contentious to say the last. Previous HN discussion: https://news.ycombinator.com/item?id=32111738 https://news.ycombinator.com/item?id=32111738
- remram 4y ago
  This gives a checkmark based on number of downloads, so there is absolutely no guarantee that the package doesn't do anything malicious or won't in the future.
woodruffw 4y ago
It's not going to be a "blue checkmark" per se, but we're currently working on integrating Sigstore signatures into PyPI. The idea there will be that you'll be able to verify that a package's distributions are signed with an identity that you trust (for example, your public email address, GitHub repository name, or GitHub handle).
dheera 4y ago
I think the issue isn't so much malicious authors, it's compromised repositories and compromised repositories as dependencies. Blue check would gatekeep a lot of noble, new developers.
- zzzeek 4y ago
  these aren't compromised repositories on pypi, these are fully legitimate repos started by bad actors that intentionally use similar sounding names and readmes. a system by which all of the major packages and dependencies are coming in, which to be clear is the whole pile of stuff that people aren't usually looking at, on a set of trusted authors and where someone who is being careful can whitelist specific repos for newer projects they want to use would reduce the problem to almost nothing.
robertlagrant 4y ago
SQLAlchemy can get one for $20/mo : - D
- zzzeek 4y ago
  we have more than enough donations to pay for that, and since SQLAlchemy is a "critical project" they'd likely comp us anyway. but IMO they'd never charge for such a thing, that's not at all in the spirit of OSS / python dev.
deleted 4y ago
[deleted]
peteatphylum 4y ago
This is the double-edged sword of open-source. It's awesome because anyone can contribute. It can be dangerous for the same reason, unfortunately.
remram 4y ago
I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address. I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to trust your colleagues or specific people rather than the package authors. This seems like a much more viable solution to scale trust. [1]: https://github.com/crev-dev/crev https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet
- peteatphylum 4y ago
  We've found a lot of open-source packages that are authored by (well, released by authors identified by) disposable email addresses. We were shocked to find companies doing this, too. Package Dependency land is a crazy place
  - remram 4y ago
    The reason is obvious, people crawl pypi.org/github.com/npmjs.com and email their job posts or product launches. Every platform that requires an email and shows it publicly will necessarily get a lot of disposable ones.
7373737373 4y ago
Identity verification will never be enough, if their account or anything in their development or distribution pipeline is compromised, so will their code. Sandboxing mechanisms are fundamentally required - not only to ward off malicious attacks there, but to prevent accidental side effects and compromise at runtime too.
- zzzeek 4y ago
  yes I knew someone would say, "that wont solve the problem!" it would certainly make it way better. it is much more difficult to hack someone's account and bypass their two-factor authentication instead of literally uploading any number of randomly named packages at will. the same argument can be applied to, "when you park on the street in manhattan, close your windows and lock your doors". Well that won't save your car from being compromised. But it will certainly make it way less likely that someone will steal something out of your car.

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons.

by zzzeek 4y ago

can there be a "blue checkmark" system for pypi authors? I'm sure that's been brought up and rejected for reasons.

Yes, this lines up with the "Critical Project" concept that has been floating around in the past year. It is... contentious to say the last. Previous HN discussion: https://news.ycombinator.com/item?id=32111738 https://news.ycombinator.com/item?id=32111738

remram 4y ago
This gives a checkmark based on number of downloads, so there is absolutely no guarantee that the package doesn't do anything malicious or won't in the future.

woodruffw 4y ago

It's not going to be a "blue checkmark" per se, but we're currently working on integrating Sigstore signatures into PyPI. The idea there will be that you'll be able to verify that a package's distributions are signed with an identity that you trust (for example, your public email address, GitHub repository name, or GitHub handle).

dheera 4y ago

I think the issue isn't so much malicious authors, it's compromised repositories and compromised repositories as dependencies. Blue check would gatekeep a lot of noble, new developers.

zzzeek 4y ago
these aren't compromised repositories on pypi, these are fully legitimate repos started by bad actors that intentionally use similar sounding names and readmes. a system by which all of the major packages and dependencies are coming in, which to be clear is the whole pile of stuff that people aren't usually looking at, on a set of trusted authors and where someone who is being careful can whitelist specific repos for newer projects they want to use would reduce the problem to almost nothing.

robertlagrant 4y ago

SQLAlchemy can get one for $20/mo : - D

zzzeek 4y ago
we have more than enough donations to pay for that, and since SQLAlchemy is a "critical project" they'd likely comp us anyway. but IMO they'd never charge for such a thing, that's not at all in the spirit of OSS / python dev.

deleted 4y ago

[deleted]

peteatphylum 4y ago

This is the double-edged sword of open-source. It's awesome because anyone can contribute. It can be dangerous for the same reason, unfortunately.

remram 4y ago

I don't think it makes much sense to verify pypi authors. I mean you could verify corporations and universities and that would get you far, but most of the packages you use are maintained by random people who signed up with a random email address. I think it makes more sense to verify individual releases. There are tools in that space like crev [1], vouch [2], and cargo-vet [3] that facilitate this, allowing you to trust your colleagues or specific people rather than the package authors. This seems like a much more viable solution to scale trust. [1]: https://github.com/crev-dev/crev https://github.com/crev-dev/crev [2]: https://github.com/vouch-dev/vouch https://github.com/vouch-dev/vouch [3]: https://github.com/mozilla/cargo-vet https://github.com/mozilla/cargo-vet

peteatphylum 4y ago
We've found a lot of open-source packages that are authored by (well, released by authors identified by) disposable email addresses. We were shocked to find companies doing this, too. Package Dependency land is a crazy place
- remram 4y ago
  The reason is obvious, people crawl pypi.org/github.com/npmjs.com and email their job posts or product launches. Every platform that requires an email and shows it publicly will necessarily get a lot of disposable ones.

7373737373 4y ago

Identity verification will never be enough, if their account or anything in their development or distribution pipeline is compromised, so will their code. Sandboxing mechanisms are fundamentally required - not only to ward off malicious attacks there, but to prevent accidental side effects and compromise at runtime too.

zzzeek 4y ago
yes I knew someone would say, "that wont solve the problem!" it would certainly make it way better. it is much more difficult to hack someone's account and bypass their two-factor authentication instead of literally uploading any number of randomly named packages at will. the same argument can be applied to, "when you park on the street in manhattan, close your windows and lock your doors". Well that won't save your car from being compromised. But it will certainly make it way less likely that someone will steal something out of your car.