[Distutils] GnuPG signatures on PyPI: why so few?

[Steve Dower]

Another drive-by contribution: what if twine printed the hashes for anything it uploads with a message basically saying "here are the things you should publish somewhere for this release so people can check the validity of your packages after they download them"?

I suspect many publishers have never considered this is something they could or should do. Some very basic prompting could easily lead to it becoming part of the normal workflow.

Top-posted from my Windows Phone

-----Original Message-----
From: "Nick Coghlan" <ncoghlan at gmail.com>
Sent: ‎3/‎13/‎2017 0:53
To: "Glyph Lefkowitz" <glyph at twistedmatrix.com>
Cc: "DistUtils mailing list" <Distutils-Sig at python.org>; "Ben Finney" <ben+python at benfinney.id.au>
Subject: Re: [Distutils] GnuPG signatures on PyPI: why so few?

On 13 March 2017 at 05:51, Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:

To summarize: Even if we only cared about supplying package upstreams to Debian (and that is a tiny part of PyPI's mission), right now, using the existing tooling of uscan and lintian, the only security value that could _possibly_ be conveyed here would be an out-of-band conversation between the maintainer and upstream about what their signing keys are and how the signing process works.  Any kind of automation would make it less likely that would happen, which means that providing tool support to automate this process would actually make things worse.


And much of the same benefits can be obtained by Debian and other third parties maintaining "known hashes" for historical PyPI releases and complaining if they ever change.


The only aspect that end-to-end package signing can potentially help with is bypassing PyPI as a potential point of compromise for *new* never-before-seen releases, and much of *that* benefit can be gained by way of publishers providing a list of "expected artifact hashes" through a trusted channel that they control and the PyPI service can't influence.


GPG signatures of the artifacts themselves is just one way of establishing that trusted information channel, and it's a particularly publisher-hostile one that's also pretty end-user-hostile as well.


The TUF based approach in PEP 458 and PEP 480 has at least in principle support from both Donald and I, but in addition to still relying on HTTPS to bootstrap initial trust, it is also gated behind the Warehouse migration and shutting down the legacy PyPI implementation (which is a sufficiently tedious activity that we think the chances of achieving it with purely volunteer and part-time labour are basically zero).



Cheers,

Nick.


-- 

Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170313/f54c3709/attachment.html>