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

[Glyph Lefkowitz]

The big problem here, of course, is "key management"; what happens when someone throws their laptop in a river.

https://github.com/ahf/teneo indicates to me that it may be possible to use a KDF to get an Ed25519 key from a passphrase that the user remembers, minilock-style, largely mitigating that problem, assuming we can get users to remember stuff :-).

-g

> On Mar 14, 2017, at 7:35 AM, Daniel Holth <dholth at gmail.com> wrote:
> 
> 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 <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 <mailto:ncoghlan at gmail.com>> wrote:
> On 14 March 2017 at 15:48, Glyph Lefkowitz <glyph at twistedmatrix.com <mailto: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 <mailto:ncoghlan at gmail.com>   |   Brisbane, Australia
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org <mailto:Distutils-SIG at python.org>
> https://mail.python.org/mailman/listinfo/distutils-sig <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/d10ae33f/attachment-0001.html>