FD: I’ve done some work on PyPI, but I am not an admin and everything below is an independent opinion/understanding.
PyPI’s operational costs are, to my understanding, mostly covered: hosting is graciously provided by a sponsor, and the PSF currently funds roles for its develop, administration, and security. More funding is always good and I believe the PyPI admins are looking to enable payments through the newly released “Organizations” feature[1].
Edit: and to make it more clear: payments for Organizations would be principally aimed at corporations and other groups.
> Additionally, if pypi provides keys to developers, pypi can also revoke certificates for developers making malicious packages.
There are currently plans in progress to allow PyPI users to upload Sigstore[2] signatures for packages.
That won’t directly address the spam issue, however — signatures will be opt-in (by necessity, due to the size of the packaging ecosystem), and no codesigning scheme can prevent a spammer from simply assuming a new identity (especially when new identities are “free,” as they normally are.)
Separately, revocation itself is a nasty problem for packaging ecosystems to deal with: ecosystems with trillions of dollars of value behind them (like the Web PKI) struggle with it, so it’s not immediately clear that it would be anything other than an additional operational burden.
Similarly for reputational systems: they’re difficult to operationalize without additional maintainer burden. That’s not to say that they’re necessarily bad or impractical for PyPI’s purposes; only that I’m not aware of a successful use of them in an open source packaging ecosystem. Compare, for example, PGP’s WoT failures.
Web of Trust failed because it lacked motivating reasons to use it, and had a very weird idea about how trust is represented (i.e. the idea of partial trust keys meaning... What exactly?)
What was missing was a role/application based idea of trust chains. i.e. what I trust to do my banking is quite different to what I trust for software reputation.
Because ultimately we're operating a web of trust system now on the internet, it's just informally specified.
> Web of Trust failed because it lacked motivating reasons to use it, and had a very weird idea about how trust is represented (i.e. the idea of partial trust keys meaning... What exactly?)
This is true, but it's also just one among several reasons that the PGP WoT failed. Some are purely implementation and design failures that wouldn't imply to a better scheme than PGP, but others are still intractable in the general case (like timely revocations and "strong set" maintenance).
> Because ultimately we're operating a web of trust system now on the internet, it's just informally specified.
Could you elaborate on what you mean by this? The trust scheme that the modern web is built on is a well-specified hierarchical PKI, i.e. the exact opposite of a web of trust. But it's possible I'm misunderstanding what you mean.
I don't know that I agree with this framing. Pgp could support multiple keyrings, for one.
Bigger, though, is that the internet isn't a web of trust in the same vein? Take out the CA chain, and websites fail trust pretty hard. Even adding them, we wind up accepting certificate pinning on browsers, as nobody has a better option, yet.
And that is building trust to web sites. The stick houses we have to trust communication is basically, "you always call us."
Edit: forgot to say that partial trust is pretty close to "believed, but I wouldn't bank with this identity."
Didn’t know sigstore. The idea looks promising. They should work on marketing though.
“Their” technology would work on any package repository, right? Also for npm and the likes.
PyPI’s operational costs are, to my understanding, mostly covered: hosting is graciously provided by a sponsor, and the PSF currently funds roles for its develop, administration, and security. More funding is always good and I believe the PyPI admins are looking to enable payments through the newly released “Organizations” feature[1].
Edit: and to make it more clear: payments for Organizations would be principally aimed at corporations and other groups.
> Additionally, if pypi provides keys to developers, pypi can also revoke certificates for developers making malicious packages.
There are currently plans in progress to allow PyPI users to upload Sigstore[2] signatures for packages.
That won’t directly address the spam issue, however — signatures will be opt-in (by necessity, due to the size of the packaging ecosystem), and no codesigning scheme can prevent a spammer from simply assuming a new identity (especially when new identities are “free,” as they normally are.)
Separately, revocation itself is a nasty problem for packaging ecosystems to deal with: ecosystems with trillions of dollars of value behind them (like the Web PKI) struggle with it, so it’s not immediately clear that it would be anything other than an additional operational burden.
Similarly for reputational systems: they’re difficult to operationalize without additional maintainer burden. That’s not to say that they’re necessarily bad or impractical for PyPI’s purposes; only that I’m not aware of a successful use of them in an open source packaging ecosystem. Compare, for example, PGP’s WoT failures.
[1]: https://blog.pypi.org/posts/2023-04-23-introducing-pypi-orga...
[2]: https://www.sigstore.dev/