<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" 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 12, 2017, at 5:13 AM, Ben Finney <<a href="mailto:ben+python@benfinney.id.au" class="">ben+python@benfinney.id.au</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Paul Moore <<a href="mailto:p.f.moore@gmail.com" class="">p.f.moore@gmail.com</a>> writes:<br class=""><br class=""><blockquote type="cite" class="">One tool that needs improvement to be easier to use for this to happen<br class="">is GPG itself.<br class=""></blockquote><br class="">No disagreement from me on that. And indeed, the GnuPG project's chronic<br class="">under-funding eventually drew attention from the new Core Infrastructure<br class="">Initiative <URL:<a href="https://www.coreinfrastructure.org/gnupg" class="">https://www.coreinfrastructure.org/gnupg</a>> to improve it<br class="">faster than was historically the case.<br class=""><br class="">This is thanks in large part to the amazing work of Nadia Eghbal<br class=""><URL:<a href="http://nadiaeghbal.com/oss" class="">http://nadiaeghbal.com/oss</a>> in drawing attention to how critical<br class="">free software, such as GnuPG, benefits society enormously and must<br class="">receive reliable funding from the organisations who benefit.<br class=""><br class="">If anyone reading this works for any organisation that wants to ensure<br class="">such critical free-software infrastructure continues to be consistently<br class="">funded and maintained, encourage regular financial contribution to the<br class="">Core Infrastructure Initiative <URL:<a href="https://www.coreinfrastructure.org/" class="">https://www.coreinfrastructure.org/</a>><br class="">or similar projects.<br class=""></div></div></blockquote><div><br class=""></div><div>No disrespect to GPG's maintainers, who are indeed beleaguered and underfunded, but the poor usability of the tool isn't entirely down to a lack of resources.</div><div><br class=""></div><div>One reason we may not want to require or even encourage the use of GPG is that <i class="">GPG is bad</i>. Publishing your own heartfelt screed about why you used to like GPG but really, we need to abandon it now, has become the national sport of the information security community:</div><div><br class=""></div><div><a href="https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/" class="">https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/</a></div><div><a href="https://blog.filippo.io/giving-up-on-long-term-pgp/" class="">https://blog.filippo.io/giving-up-on-long-term-pgp/</a></div><div><a href="https://moxie.org/blog/gpg-and-me/" class="">https://moxie.org/blog/gpg-and-me/</a></div><div><br class=""></div><div>These posts are talking a lot about email, but many of the problems are just fundamental; in particular the "museum of 90s crypto" aspect is fundamentally un-solvable within the confines of the OpenPGP specification. "Unusable email clients" in this case could be replaced with "unusable packaging tooling".</div><div><br class=""></div><div>If you're retrieving packages from PyPI over TLS, they're already cryptographically signed at the time of retrieval, by an entity with a very good reputation in the community (the PSF) that you already have to trust anyway because that's where Python comes from. So if we could get away from GPG as a specific piece of tooling here and focus on the <i class="">problem</i> a detached GPG signature could solve, it's "direct trust of packagers rather than the index".</div><div><br class=""></div><div>The only way that Debian maintainers can supply this trust metadata right now is to <i class="">manually populate</i> debian/upstream/signing-key.asc. This is a terrible mechanism that is full of flaws, but requiring a human being to at least <i class="">look</i> at the keys is at least a potential benefit because maybe they'll notice that it's odd that the key got rotated. If PyPI required signatures from everybody then it would be very tempting to skip this manual step and just retrieve the signing key from the PyPI account uploading the packages, which is the exact same guarantee you had before via the crypto TLS gave you (i.e. the PSF via PyPI makes some highly ambiguous attestation as to the authenticity of the package, basically just "its name matches") but now you're involving a pile of highly-complex software with fundamentally worse crypto than OpenSSL would have given you.</div><div><br class=""></div><div>To summarize: Even if we only cared about supplying package upstreams to Debian (and that is a tiny part of PyPI's mission), right now, using the existing tooling of uscan and lintian, the only security value that could _possibly_ be conveyed here would be an out-of-band conversation between the maintainer and upstream about what their signing keys are and how the signing process works. Any kind of automation would make it less likely that would happen, which means that providing tool support to automate this process would actually make things <i class="">worse</i>.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="">As a Windows user, I've "played" with it in the past, and found it<br class="">frustratingly difficult.<br class=""></blockquote><br class="">I hope many people here will find the guide published by the FSF, Email<br class="">Self-Defense <URL:<a href="https://emailselfdefense.fsf.org/" class="">https://emailselfdefense.fsf.org/</a>>, a useful walk<br class="">through how to set it up properly.<br class=""><br class="">-- <br class=""> \ “I must say that I find television very educational. The minute |<br class=""> `\ somebody turns it on, I go to the library and read a book.” |<br class="">_o__) —Groucho Marx |<br class="">Ben Finney<br class=""><br class="">_______________________________________________<br class="">Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" class="">Distutils-SIG@python.org</a><br class=""><a href="https://mail.python.org/mailman/listinfo/distutils-sig" class="">https://mail.python.org/mailman/listinfo/distutils-sig</a><br class=""></div></div></blockquote></div><br class=""></div></body></html>