On May 12, 2016, at 3:05 PM, Barry Warsaw <barry@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