<div dir="ltr">Or they could be printed as QR codes.<div><br></div><div>An interesting secure time service: <a href="https://roughtime.googlesource.com/roughtime">https://roughtime.googlesource.com/roughtime</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 15, 2017 at 1:49 AM Glyph Lefkowitz <<a href="mailto:glyph@twistedmatrix.com">glyph@twistedmatrix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">The big problem here, of course, is "key management"; what happens when someone throws their laptop in a river.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><a href="https://github.com/ahf/teneo" class="gmail_msg" target="_blank">https://github.com/ahf/teneo</a> 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 :-).</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">-g</div></div><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Mar 14, 2017, at 7:35 AM, Daniel Holth <<a href="mailto:dholth@gmail.com" class="gmail_msg" target="_blank">dholth@gmail.com</a>> wrote:</div><br class="m_6473204442379822299Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div dir="ltr" class="gmail_msg">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 <a href="https://www.googleapis.com/oauth2/v3/certs" class="gmail_msg" target="_blank">https://www.googleapis.com/oauth2/v3/certs</a><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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'.</div></div><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Mar 14, 2017 at 2:52 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On 14 March 2017 at 15:48, Glyph Lefkowitz <span dir="ltr" class="gmail_msg"><<a href="mailto:glyph@twistedmatrix.com" class="gmail_msg" target="_blank">glyph@twistedmatrix.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><span class="gmail_msg"></span><div class="gmail_msg">2. Except, as stated - i.e. hashes without signatures - this just means we all trust Github rather than PyPI :).</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Cheers,<br class="gmail_msg"></div><div class="gmail_msg">Nick.<br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><br class="gmail_msg">-- <br class="gmail_msg"><div class="gmail_msg m_6473204442379822299m_1386518905140276840gmail_signature" data-smartmail="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" class="gmail_msg" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>
_______________________________________________<br class="gmail_msg">
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" class="gmail_msg" target="_blank">Distutils-SIG@python.org</a><br class="gmail_msg">
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" class="gmail_msg" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></div><br class="gmail_msg"></div></blockquote></div>