Removal of any signatures system

As far I could see, the only thing related to OpenPGP key management was a field where you could put 32-bit(!) key ID. But this field wasn't used for anything.

There were two distinct features that dealt with PGP signatures on PyPI:

1. The ability to associate a PGP key identity with your user account.
2. The ability to upload a detached signature alongside the file during upload, and having that available for download, and displayed in the UI.

These two features were, as far as the code itself was concerned, entirely unrelated. You could (and still can) submit a detached signature using any key that you possess regardless of what PyPI thinks your public key is via the mechanism in (1). The only purpose to the mechanism in (1) is to allow people to discover what your public key is, theoretically to them allow them to validate the signatures if you used that public key.

So what's changed in the new PyPI?

Well (1) is gone, because it is almost entirely pointless. The only way to add or get the information stored in that field is using a HTTP request protected by TLS. If you rely on trusting that field, then the security of the system you've created devolves into trusting TLS, and if you're trusting TLS then you might as well trust TLS for everything and not just one part of it.

(2) still exists and works, you can still sign files with whatever key you possess and upload a detached signature as part of the file upload. The only thing that has changed in regards to (2) is that we will no longer indicate in the UI if a file has been PGP signed or not, nor provide a link in the UI to download it. The file is still available for download (using the URL specified in PEP 503) and it is still possible to upload signatures.

The system still works almost entirely the same as it always has, the only differences are we're not exposing the signature in the UI anymore, and you no longer have a little text field to publish what your public key identity is for a specific user.

We've removed the PGP signatures from the UI in an attempt to de-emphasize them. They are largely pointless in their current implementation because they lack a coherent trust model that applies to the packaging domain. You could build a secure package signing protocol ontop of PGP, but you'd do so by effectively throwing out the WOT portions of PGP. Personally I'd rather remove them entirely, because I think they are 99% security theater in their current implementation, but folks argued against doing that until the replacement was in place, and the code was already written to support them, so I conceded.

As far as the removal of the little text field to publish your public key, that is gone in the new PyPI because it was 100% pointless. I don't even think it was even exposed to end users anywhere, but if it was, you couldn't actually use it for anything. If you're trying to design a secure crpytosystem ontop fo the features that PyPI has, the only point in that field would be to make a HTTPS request to PyPI to ask what the author's public key is so you could verify that the signature was made by an authorized key. However at that point you're trusting HTTPS to tell you who to trust to sign a package, and if you assume HTTPS is not trustworthy, then a malicous attacker could just tell you to use their own key rather than the author's key. So at that point any system which used that, was effectively as secure as relying only on HTTPS.