<div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mar 11, 2017 6:47 PM, "Ben Finney" <<a href="mailto:bignose@debian.org">bignose@debian.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy all,<br>
<br>
What prospects are there for PyPI to have GnuPG-signed packages by default?<br>
<br>
Debian's UScan has the ability to find, download, and verify the GnuPG<br>
signature for a package source release. Lintian will remind the<br>
maintainer if a Debian source package is not taking advantage of this.<br>
<br>
However, this only works if upstream releases are actually accompanied<br>
by a valid GnuPG signature each time. The PyPI infrastructure supports<br>
this; why isn't it more widely encouraged?<br>
<br>
This thread from 2016 has a possible answer:<br>
<br>
while you can use GPG as is to verify that yes, "Donald Stufft"<br>
signed a particular package, you cannot use it to determine if<br>
"Donald Stufft" is *allowed* to sign for that package, a valid<br>
signature from me on the requests project should be just as invalid<br>
as an invalid signature from anyone on the requests project. The<br>
only namespacing provided by GPG itself is "trusted key" vs "not<br>
trusted key".<br>
<br>
[…] I am aware of a single tool anywhere that actively supports<br>
verifying the signatures that people upload to PyPI, and that is<br>
Debian's uscan program. […]<br>
<br>
All in all, I think that there is not a whole lot of point to having<br>
this feature in PyPI, it is predicated a bunch of invalid<br>
assumptions (as detailed above) and I do not believe end users are<br>
actually even using the keys that are being uploaded.<br>
<br>
[…] Thus, I would like to remove this feature from PyPI […].<br>
<br>
<URL:<a href="https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>pipermail/distutils-sig/2016-<wbr>May/028933.html</a>><br>
<br>
The thread has some discussion, and Barry Warsaw makes the case for<br>
Debian's use for signed releases. The last (?) post in the thread has a<br>
kind of interim conclusion:<br>
<br>
My main concern when implementing this is how to communicate it to<br>
users […]. [A move that gives the impression] "we're getting rid of<br>
this thing that only kinda works now in favor of something amazing<br>
that doesn't exist yet" is just not a popular move.<br>
<br>
<URL:<a href="https://mail.python.org/pipermail/distutils-sig/2016-May/028946.html" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>pipermail/distutils-sig/2016-<wbr>May/028946.html</a>><br>
<br>
In response to polite requests for signed releases, some upstream<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I've only ever seen condescending requests in the past but perhaps we have different definitions of "polite" or perhaps things have genuinely changed.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
maintainers are now pointing to that thread and closing bug reports as<br>
“won't fix”.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">You may have noticed in that thread that there are plans for better mechanisms. Mechanisms that don't add significantly more burden to maintainers of the software we know and love who do this for free and with their spare time.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What prospect is there in the Python community to get signed upstream<br>
releases become the obvious norm?</blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Not every package on PyPI is redistributed via Linux packagers. Why then should someone publishing their tiny little first package have to go through the hassle of creating a GPG key?</div><div dir="auto"><br></div><div dir="auto">As a maintainer of Twine, I will never force someone to have learned how to install GPG on their platform, create a key that package maintainers won't belittle them for, and maintain the key's security in order to upload something to PyPI.</div><div dir="auto"><br></div><div dir="auto">Further GPG depends on trust. Do you mean to imply that Debian trusts PyPI packages with a signature more than those without? Even if the key used to sign it has never been signed by another person? What about keys signed by people you've never met? Someone can manufacture their own web of trust if they want to. Why is GPG seen as done kind of magic authenticity bullet?</div><div dir="auto"><br></div><div dir="auto">If you can find a tool that is easy to install on Linux, Windows, and Mac, which solves the problems above by virtue of having very good defaults, and is accessible to anyone with less than a few hours to waste on it... Then maybe I would collaborate to make it a requirement.</div></div>