[Distutils] GnuPG signatures on PyPI: why so few?

[Ian Cordasco]

On Mar 11, 2017 6:47 PM, "Ben Finney" <bignose at debian.org> wrote:

Howdy all,

What prospects are there for PyPI to have GnuPG-signed packages by default?

Debian's UScan has the ability to find, download, and verify the GnuPG
signature for a package source release. Lintian will remind the
maintainer if a Debian source package is not taking advantage of this.

However, this only works if upstream releases are actually accompanied
by a valid GnuPG signature each time. The PyPI infrastructure supports
this; why isn't it more widely encouraged?

This thread from 2016 has a possible answer:

    while you can use GPG as is to verify that yes, "Donald Stufft"
    signed a particular package, you cannot use it to determine if
    "Donald Stufft" is *allowed* to sign for that package, a valid
    signature from me on the requests project should be just as invalid
    as an invalid signature from anyone on the requests project. The
    only namespacing provided by GPG itself is "trusted key" vs "not
    trusted key".

    […] I am aware of a single tool anywhere that actively supports
    verifying the signatures that people upload to PyPI, and that is
    Debian's uscan program. […]

    All in all, I think that there is not a whole lot of point to having
    this feature in PyPI, it is predicated a bunch of invalid
    assumptions (as detailed above) and I do not believe end users are
    actually even using the keys that are being uploaded.

    […] Thus, I would like to remove this feature from PyPI […].

    <URL:https://mail.python.org/pipermail/distutils-sig/2016-
May/028933.html>

The thread has some discussion, and Barry Warsaw makes the case for
Debian's use for signed releases. The last (?) post in the thread has a
kind of interim conclusion:

    My main concern when implementing this is how to communicate it to
    users […]. [A move that gives the impression] "we're getting rid of
    this thing that only kinda works now in favor of something amazing
    that doesn't exist yet" is just not a popular move.

    <URL:https://mail.python.org/pipermail/distutils-sig/2016-
May/028946.html>

In response to polite requests for signed releases, some upstream


I've only ever seen condescending requests in the past but perhaps we have
different definitions of "polite" or perhaps things have genuinely changed.

maintainers are now pointing to that thread and closing bug reports as
“won't fix”.


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.


What prospect is there in the Python community to get signed upstream
releases become the obvious norm?


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?

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.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170311/aec12691/attachment-0001.html>