<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 13, 2017, at 9:23 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" class="">ncoghlan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On 14 March 2017 at 03:46, Steve Dower <span dir="ltr" class=""><<a href="mailto:steve.dower@python.org" target="_blank" class="">steve.dower@python.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class=""><div style="font-family:calibri,sans-serif;font-size:11pt" class="">Another drive-by contribution: what if twine printed the hashes for anything it uploads with a message basically saying "here are the things you should publish somewhere for this release so people can check the validity of your packages after they download them"?<br class=""><br class="">I suspect many publishers have never considered this is something they could or should do. Some very basic prompting could easily lead to it becoming part of the normal workflow.<span class="gmail-"><br class=""></span></div></div></div></blockquote><div class=""><br class=""></div><div class="">Huh, and with most PyPI publishers using public version control systems, their source control repo itself could even serve as "a trusted channel that they control and the PyPI service can't influence". For example, the artifact hashes could be written out by default to:<br class=""><br class=""></div><div class=""> .released_artifacts/<version>/<artifact_name>.sha256<br class=""><br class=""></div><div class="">And if twine sees the hash file exists before it starts the upload, it could complain that the given artifact had already been published even before PyPI complains about it.<br class=""></div></div></div></div></div></blockquote><br class=""></div><div>1. This sounds like it <i class="">could</i> be very cool.</div><div><br class=""></div><div>2. Except, as stated - i.e. hashes without signatures - this just means we all trust Github rather than PyPI :).</div><div><br class=""></div><div>3. A simple signing scheme, like <a href="https://minilock.io" class="">https://minilock.io</a> but <a href="https://github.com/kaepora/miniLock/issues/198" class="">for plaintext signatures rather than encryption</a>, could potentially address this problem.</div><div><br class=""></div><div>4. Cool as that would be, someone would need to design that thing first, and that person would need to be a cryptographer.</div><div><br class=""></div><div>5. Now all you need to do is design a globally addressable PKI system. Good luck everybody ;-).</div><div><br class=""></div><div>-glyph</div><div class=""><br class=""></div></body></html>