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" <ncogh...@gmail.com>
Sent: 3/13/2017 0:53
To: "Glyph Lefkowitz" <gl...@twistedmatrix.com>
Cc: "DistUtils mailing list" <Distutils-Sig@python.org>; "Ben Finney"
<ben+pyt...@benfinney.id.au>
Subject: Re: [Distutils] GnuPG signatures on PyPI: why so few?
On 13 March 2017 at 05:51, Glyph Lefkowitz <gl...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
