I'm the author of that post. There is absolutely no meaningful sense in which PyPI's previous PGP support was (or ever did) provide end-to-end package signing. At the absolute most, when used correctly (which, overwhelmingly, it was not), it provided one half of package signing.
The other half (key retrieval and identity binding) was never provided, because PGP as an ecosystem made doing so intractable. It was not better than nothing, because it was nothing; anything you could have done with it can be done with your own sidecar signatures.
PGP didn't make it intractable, the problem is itself intractable... you're referring to the public key infrastructure (PKI)[1] problem, which many have tried to solve and failed.
PGP can use the only known solution to the problem, which is letting several key servers be configured by the user to import keys (which can then be verified by checking the key fingerprint on another source which is "trusted", like the publisher's own website).
You can still import keys by physically exchanging trusted keys with others (so called Key Signing Party[2]) but that obviously cannot scale... or using any innovative method you come up with, but no one has found a bullet proof way to do this that's usable.
But saying PGP only solves half the problem is wrong. It solves one problem: that of how to verify a publisher's artifacts were not modified, which is valuable.
The next problem to solve is how to obtain and vet public keys from publishers. The solution could work somewhat like TLS certificates (with certificate authorities playing the role of trusted key servers) or using blockchain (perhaps a rare problem for which blockchain could actually be helpful) but both of these bring their own issues with them. If you know of a better solution, though, do bring it up instead of throwing the bathwater out with the "baby"!
I think it’d behoove you to read the original thread from yesterday: all, and more, of this was covered!
PKI is indeed hard, but it’s not even remotely intractable. The Web PKI is a functioning PKI; yesterday’s thread explains how the codesigning scheme we’re building for PyPI is going to look very similar to the Web PKI.
At the ecosystem level, PGP was not providing resource integrity to PyPI: too many of the keys involved were weak, and only a tiny proportion of packages were even signed. Even if that proportion was 100%, PGP would have been the wrong tool for that job: PyPI already has transport and resource integrity via the right tools: TLS and digests. Using an untrusted signature for resource integrity is using the wrong tool for the job.
The original thread contains multiple references to Sigstore, which is the scheme we’re planning on building on for PyPI.
Signing is basically hashing + proof of who created the hash. You need either both, or a way to find which hash is correct according to someone, usually the owner of the artifact, and signing gives you just that.
Signing is only proof of identity if you (1) know the underlying identity, and (2) actually trust that identity for intelligible reasons (i.e., you can produce a formal description of the trust relationship).
Without those two conditions, a signature is a digest produced by an untrusted party. For PyPI, that means that PGP signatures are no better than (and in some senses, worse) than PyPI's own digests, since PyPI at least is a currently trusted party.
A centralized host can't ever be the only reasonable option for trust. They can be manipulated, technically or socially, and that makes everything vulnerable at once.
The Web PKI is built around centralized roots of trust, and survives because of concerted efforts to make those roots resilient, trustworthy (in terms of underlying ownership), and publicly auditable (with mechanisms like CT).
To the best of my knowledge, there has never been a successful decentralized PKI. Even the most successful uses of PGP are not decentralized; they're essentially private PKIs maintained by a small set of presumed trustworthy maintainers.
PGP absolutely is decentralized - I can trust or distrust key X without communicating at all with any external PKI.
I agree that's not all that useful on a global scale - it essentially degrades to the current PKI setup then, because validating everything is expensive and doesn't need to be done by everyone every time to get nearly all of the benefit. But it is a significant difference for individuals making individual decisions.
But a hash provides proof to the actual uploader of subsequent tampering. As you cannot modify the hash without the originator being aware, I think it is enough.
Every security design is built out of a matrix of factors, and some (but not all) of those factors can be made zero.
Being unable to verify your trusted identities in a PKI is one such “zero factor.” It makes the PKI strictly equivalent to (crappy) resource integrity at the best, which is when everything is signed. PGP on PyPI didn’t even manage to clear that hurdle; it was worse than nothing by virtue of advertising properties that it was incapable of providing. That too is a zero-able factor in a security design.
Actually, it very commonly is an all-or-nothing process. It doesn't matter how robust the lock on your front door is, if there is no lock on the back door, or if your window can be smashed. This especially true when it comes to cryptographic security, which is the subject at hand.
I suspect the source of your confusion comes from the idea of differential security, which is approximately "I don't need the best lock; I just need a better lock than the other guy". Again, note that this does not apply to cryptographic signing of packages. Note also that the question of whether or not your system actually is more secure than the other guy's is very much a binary distinction: it either is or it isn't. You can quantify this quite easily by counting vulnerabilities, or by analyzing the degree of access gained for each vulnerability that is encountered.
So yeah, it's one of the few things that tends to be all-or-nothing (up to some threat model, of course).
The other half (key retrieval and identity binding) was never provided, because PGP as an ecosystem made doing so intractable. It was not better than nothing, because it was nothing; anything you could have done with it can be done with your own sidecar signatures.