Re: GnuPG signatures on PyPI: why so few?
Donald Stufft:
>
>> On Mar 12, 2017, at 10:35 PM, Paul Wise <pabs@debian.org> wrote:
>>
>> On Mon, Mar 13, 2017 at 4:28 AM, Jeremy Stanley wrote:
>>
>>> upload them to PyPI since the authors of the coming Warehouse
>>> replacement for the current CheeseShop PyPI have already indicated
>>> that they intend to drop support for signatures entirely.
>>
>> Did they give any reasoning for this decision?
>>
>
>
> https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html <https://mail.python.org/pipermail/distutils-sig/2016-May/028933.html>
>
> —
> Donald Stufft
Your analysis makes sense: the hardest part of this problem is managing
_who_ is the trusted signer of a given package. TOFU
(Trust-On-First-Use) is the easy case here: the first person to sign the
release is the one to trust. Android's APK signature verification for
updates is entirely based on that principal.
It seems that so many Python and Java library developers (mavenCentral
is in a similar boat to PyPi) just want to ignore the signing key
management because its annoying. Yes, it is annoying, I do a lot of it.
Android forces all devs to manage a signing key: unsigned APKs are not
installable, and Google Play even rejects APKs signed by debug keys.
I think the Android/Google Play model would work quite well for PyPI,
but the social problem of getting python devs to take responsibility
would be the hard part. I manages the transition of F-Droid app repos
to only signed, which is a small example. There were some complaints,
but nothing so bad when we pointed them to the fdroid tool that
automatically generated the signing key for them. pip can easily
generate and use a signing key (GPG, TUF, whatever) automatically. Then
devs just need to learn out to safely manage them. Android Studio's key
generation is pretty new, and has kind of shitty security
recommendations. Android devs are still learning, but I think overall,
its working out well there.
As for TUF (The Update Framework), I know the concepts well. I've
looked into it while implementing the F-Droid security model
(https://f-droid.org/wiki/page/Security_Model). It does not deal with
the issue of managing identity of package uploaders at all, it assumes
you already have all the software in place, and just deals with
distributing updates. Also, with TUF, you'll be in the exact same boat
here: signing keys are required per package stream, so each developer
will need to managing signing keys.
.hc
Reply to: