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 <dho...@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 <ncogh...@gmail.com > <mailto:ncogh...@gmail.com>> wrote: > On 14 March 2017 at 15:48, Glyph Lefkowitz <gl...@twistedmatrix.com > <mailto:gl...@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 | ncogh...@gmail.com <mailto:ncogh...@gmail.com> | > Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > <mailto:Distutils-SIG@python.org> > https://mail.python.org/mailman/listinfo/distutils-sig > <https://mail.python.org/mailman/listinfo/distutils-sig>
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
