[Distutils] PyPI and GPG Signatures

[Donald Stufft]

> On May 12, 2016, at 3:05 PM, Barry Warsaw <barry at python.org> wrote:
> 
> On May 12, 2016, at 07:41 AM, Donald Stufft wrote:
> 
>> 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.
> 
> I like that uscan provides this feature, but I don't know how many packages
> actually use it, either within the Debian Python teams, or in the larger
> Debian community.  I'd like to use it more often on packages I maintain but
> it's kind of difficult to find your way back to an authoritative signing key.
> For my own packages that I also maintain in Debian, it's of course trivial, so
> I have that enabled for them.  I sign all my package uploads to PyPI, and I
> mostly trust myself <wink>.
> 
> If it's possible to get signing keys from PyPI, I really have no idea how to
> do that.  The web ui doesn't at all make it obvious (to me, at least).

You know, I went and poked at it again because I knew I had see it previously,
and I realized the only place you can see the GPG key is:

* Your own details page.
* The "Roles" page for a project that you're the maintainer or owner of.

So even as implemented on PyPI the ability to record what a particular user's
GPG key is, is practically worthless.

> 
> I understand the implementation dilemma for Warehouse, but rather than ditch
> this feature, I'd rather see it improve by making the signing keys more
> discoverable and verifiable.  I wonder if keybase.io could be used somehow.
> Or perhaps a prominent link in the package metadata pointing to a pubkey
> location.  Then it would be up to projects to utilize these mechanisms to make
> their signing keys obvious, and tools like uscan can increase their usage of
> such features.

So my response to this is, let's pretend for a minute that we have the greatest
and most amazing setup for verifying that the key 0x6E3CBCE93372DCFA belongs to
me. What's your next step? How do you verify that I'm allowed to release for
pip? What happens if tomorrow I decide I'm no longer going to use key
0x6E3CBCE93372DCFA because it got compromised (remembering that key revocation
is hilariously broken [1]). What if we add a new signing key because I'm tired
of releasing pip and someone else is going to take over, what path is Debian
going to take for verifying that some new key is allowed to sign for it that
doesn't put "Whatever PyPI says" in the path of trust?

The problem isn't just that it's a bit annoying to implement in Warehouse, but
also that GPG's trust model is not really useful at all for package signing
except in very specific scenarios which we don't have (basically just Linux
distros or some other thing, and even then the trust model isn't that useful
they just hack it with a custom trust keychain). If I find some time I might
try and get some data on it, but I greatly suspect that approaching 100% of the
traffic downloading the .asc files from PyPI are Bandersnatch automatically
mirroring them and Debian's uscan. I tried to search codesearch.debian.net but
I can't seem to make it search over multiple lines so all I can get is there
are 14 packages that have the strings `pgpsigurlmangle` and `pypi` on a single
line, but I suspect more people extend that out over two lines so I don't think
it's a meaningful number for this decision.

Overall though, I really don't think it's worth it to keep it around when the
trust model is broken and the only real consumer is Debian's uscan (and even
then, most of it's value is already taken care of by TLS).

[1] https://www.imperialviolet.org/2012/02/05/crlsets.html - Ok it's about CRL
    which is a x509 thing, but the overall point applies to GPG too.

-----------------
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/81c31553/attachment-0001.sig>