You can read more about it here, but tl;dr is that due to the fact the basically nobody used the GPG signature support and of the people who did use it, nearly 2/3 of the uploaded signatures in the last year were made by keys that could not meaningfully be validated.
It’s worth pointing out that at least some of the lack of use was
not necessarily due to a lack of desire for the feature, but rather
repeated signals that it could (and likely would) go away at any
time.
Because the PyPI admins had been talking about removing it even
during the Cheeseshop days, and the direction with Warehouse
development indicated OpenPGP signature support would be omitted
then as well (to make room for TUF), at least the OpenStack
community made the decision to publish signatures for all their
packages on a completely separate site rather than continue
uploading them to PyPI.
I would not be surprised if other large communities came to similar
conclusions and solutions for attestation of their packages as well.
2 Likes
Sure! Though my numbers in 2016 were only a little bit better, 4% of uploads had signatures (I did not do any checking how many of them were valid), compared to 0.3% now.
Further, I do not believe that anyone who has seriously worked on PyPI security in the past 10? 15? years considered GPG to be part of the solution, rather than being a weird vestigial thing that just happened to still exist.
1 Like
A definite up-side here is that I finally get to stop explaining to
users why we aren’t publishing our OpenPGP signatures to
PyPI. 
6 Likes
I’m sad to see this decision. Software signatures are not the entire solution, but if you do have a means of verying the owner of a key, you could verify the software you’ve downloaded is from a trusted source.
The number of people uploading packages with signatures is irrelevant. What matters is that some people have a subset of packages with signatures that they trust. This vastly limits the pool of packages, but that’s the point.
If you put in the work to validate the signers (and that need not be through public keyservers) it’s unfortunate you can no longer check the package signatures.
Perhaps GPG isn’t the greatest tool, but some package signing method should be supported before removing this one. The problem is that most people aren’t using GPG correctly, but the solution here is that nobody gets to use it. I think this is a mistake.
1 Like
FWIW I upload signatures for all my projects, including pypa/build.
1 Like
As previously mentioned, you can certainly publish detached OpenPGP
signatures of all your sdists/wheels to a separate site. If users
already need to do out-of-band work to determine that they trust
your signing keys then also going somewhere else to download the
signatures (from your project site for example) isn’t a huge
stretch.
This was the compromise we arrived at long ago for the OpenStack
community’s many projects. Downstream redistributors (like those
doing packaging work in GNU/Linux distributions) know where to find
the signatures from our release automation in order to make sure
that what they retrieved from PyPI hasn’t been tampered with
at/after publication.
Yes, I agree that this isn’t a huge deal since you can publish the signatures externally, it’s just a bit annoying.
That said, I also publish signed git tags for all releases of my projects, and putting my downstream packager hat on, that is usually preferred over PyPI artifacts anyway.
I feel sad about this too. While I can publish signatures elsewhere (I’m signing git tags anyway), it’s a problem to verify the publisher of PyPI packages, and PGP signatures could be one method. PGP signatures are the only well-supported way to verify publisher without trusting a third party (at least, not around the time of verification).
2 Likes