[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GnuPG signatures on PyPI: why so few?



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
maintainers are now pointing to that thread and closing bug reports as
“won't fix”.

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

-- 
 \         “It is the fundamental duty of the citizen to resist and to |
  `\          restrain the violence of the state.” —Noam Chomsky, 1971 |
_o__)                                                                  |
Ben Finney


Reply to: