Donald Stufft: > >> On Mar 12, 2017, at 10:35 PM, Paul Wise <p...@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
