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

[Nick Coghlan]

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/46cc004e/attachment.html>