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

[Daniel Holth]

The wheel command implements but never fully realized the commands 'wheel
keygen', 'wheel sign' for a bundled signature scheme (where the signature
is inside the signed file) inspired by JAR signing and based on Ed25519
primitives + JSON web signature / JSON web key. The idea was to have wheel
automatically generate a signing key and always generate signed wheels,
since it's impossible to verify signatures if there are none. Successive
releases from the same author would tend to use the same keys; a TOFU
(trust on first use) model, a-la ssh, would warn you if the key changed.
The public keys would be distributed over a separate https:// server
(perhaps the publisher's personal web page, or an application could publish
a list of public keys for its dependencies as-tested). Instead of checking
the hash of an exact release artifact, you could use a similar syntax to
check against a particular public key and cover yourself for future
releases. Instead of key revocation, you could let the only valid signing
keys be the ones currently available at the key URL, like oauth2
https://www.googleapis.com/oauth2/v3/certs

The goal you'd want to shoot for is not 'is this package good' but 'am I
being targeted'. A log of timestamp signatures for everything uploaded to
PyPI could be very powerful here and might even be useful without publisher
signatures, so that you could at least know that you are downloading the
same reasonably old version of package X that everyone else is using. If
there was a publisher signature, the timestamp server would sign the
publisher's signature asserting 'this signature was valid at time X'.

On Tue, Mar 14, 2017 at 2:52 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 14 March 2017 at 15:48, Glyph Lefkowitz <glyph at twistedmatrix.com>
> wrote:
>
>
> 2. Except, as stated - i.e. hashes without signatures - this just means we
> all trust Github rather than PyPI :).
>
>
> Yeah, HTTPS would still be a common point of compromise - that kind of
> simple scheme would just let the repo hosting and PyPI serve as
> cross-checks on each other, such that you had to compromise both (or the
> original publisher's system) in order to corrupt both the published
> artifact *and* the publisher's record of the expected artifact hash.
>
> It would also be enough to let publishers check that the artifacts that
> PyPI is serving match what they originally uploaded - treating it as a QA
> problem as much as a security one.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170314/d224822c/attachment.html>