Currently, PyPI allows you to upload a GPG signature along with your package file as well as associate a GPG Short ID with your user. Theoretically this allows end users to not trust PyPI and instead validate end to end signatures from the original author. I've written [1] previously about package signing, and about a number of common suggestions for achieving it that don't actually do much, if anything, to increase to the security of things. The current implementation on PyPI falls into such a trap. The main problem with GPG and package signing is that a GPG key provides some guarantees (ignoring issues with the concept of a WOT) about the *identity* of the person possessing the key, however it provides no mechanism for providing any guarantees about what *capabilities* should be granted to that person. More concretely, while you can use GPG as is to verify that yes, "Donald Stufft" signed a particular package, you cannot use it to determine if "Donald Stufft" is *allowed* to sign for that package, a valid signature from me on the requests project should be just as invalid as an invalid signature from anyone on the requests project. The only namespacing provided by GPG itself is "trusted key" vs "not trusted key". PyPI offers a work around for this in the form of allowing users to associate their GPG short ID with their user profile. However this is not actually very useful because it doesn't really provide much benefit overall. The goal of signing a package on PyPI is generally to allow you to safely download the file without trusting PyPI, but if you need to trust PyPI to determine what key is allowed to sign a package, then you've not really added much in the way of additional assurances, you've just added another possible point of failure. Beyond the inherent issues with attempting to use GPG support for anything useful on PyPI there are also a number of implementation specific issues with this support. Currently you *must* use a GPG Short ID with PyPI, however the GPG Short IDs are not actually secure and can be pretty easily brute forced to have a collision, which means that people can make keys that come out to the same short ID as one that an author has in their profile. In addition, uploading a signature to PyPI is not actually validated upon upload, allowing people to upload a signature that doesn't actually validate, causing a persist failure mode (though nobody validates our signatures, so nobody ever runs into this problem). On top of all of that, I believe that there will never be a case where a tool like pip supports these GPG signatures [2]. Even if you wiped away all of the above problems, GPG is still a complex standard without great support for building tooling around it. The most reasonable way of implementing support for that would be to ship a copy of the gpg binary around for different platforms and shell out to it. However GPG is GPL licensed which means that's not something we could actually do, and even if it were, shipping binaries is not generally a reasonable thing to do for pip and anything besides pure Python is a no go. I am aware of a single tool anywhere that actively supports verifying the signatures that people upload to PyPI, and that is Debian's uscan program. Even in that case the people writing the Debian watch file have to hardcode in a signing key into it and in my experience, when faced with a validation error it's not unusual for Debian to simply disable signature checking for that project and/or just blindly update the key to whatever the new key is. All in all, I think that there is not a whole lot of point to having this feature in PyPI, it is predicated a bunch of invalid assumptions (as detailed above) and I do not believe end users are actually even using the keys that are being uploaded. Last time I looked, pip, easy_install, and bandersnatch represented something like 99% of all download traffic on PyPI and none of those will do anything with the .asc files being uploaded to PyPI (other than bandersnatch just blindly mirroring it). When looking at the number of projects actively using this feature on PyPI, I can see that 27931/591919 files on PyPI have the ``has_signature`` database field set to true, or roughly 4% of all files on PyPI, which roughly holds up when you look at the number of distinct projects that have ever uploaded a signature as well (3559/80429). Thus, I would like to remove this feature from PyPI (but not from PEP 503, if other repositories want to continue to support it they are free to). Doing this would allow simplifying code we have in Warehouse anyplace we touch uploaded files (since we almost always end up needing to branch into special behavior for files ending with .asc). It will allow us to reduce the number of concepts in the UI (what is a pgp signature? What do I do with it? etc) without simply hiding a feature (which is likely to cause confusion, why do you support it if you won't show it etc). I think it will also make releasing slightly easier for developers, since I personally know a number of authors on PyPI who don't really believe there is any value in signing their packages on PyPI, but they do it anyways because of a vague notion that they should do it. If we do it, an open question would be what we do with all of the *existing* signatures on PyPI. We could just leave them in place and stop accepting new signatures, though that still means we end up needing to branch on .asc anyplace we handle files because they'll still be a valid code path. Another option is to just simply get rid of them and act as if nobody ever uploaded them in the first place, which is my preferred option. What do folks think? Would anyone be particularly against getting rid of the GPG support in PyPI? [1] https://caremad.io/2013/07/packaging-signing-not-holy-grail/ [2] When we do implement package signing in pip, it will almost certainly be via TUF, most likely using ed25519 signatures but perhaps using RSA. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA