[Distutils] PyPI and GPG Signatures

[Donald Stufft]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160512/343ea412/attachment-0001.sig>