Or they could be printed as QR codes. An interesting secure time service: https://roughtime.googlesource.com/roughtime
On Wed, Mar 15, 2017 at 1:49 AM Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > 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 > > 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> wrote: > > On 14 March 2017 at 15:48, Glyph Lefkowitz <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 | Brisbane, Australia > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > https://mail.python.org/mailman/listinfo/distutils-sig > > >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
