PGP signatures on PyPI: worse than useless

@yossarian

> nobody ever attempting to verify them

Well, that is not true. I was approached by some Linux distro packager that my key was not signed by the releaser of the previous release... Once 😂

@jugmac00

i heard the same from another maintainer! he told me that a distro noticed that his key changed, and responded by removing verification entirely from his package.

@yossarian @jugmac00 PyPI does its very, very best to hide the existence of any signature features, so that's not very surprising that not many try to use them -- and Debian definitely noticed that one time I signed with the wrong key.
@yossarian @jugmac00 (Also this would be a lot more compelling if some alternative was presented -- as it sits, how _else_ might Debian learn if the next txtorcon is published by the same person that did that last 20?)
@meejah @yossarian @jugmac00 Why does Debian check if the next txtorcon is uploaded by the same person? Having a team upload a package is a *good* practice, I hope distributions are not actively encouraging practices that cause maintainer burn-out.
@moshez @meejah @yossarian @jugmac00 Not every project has that many maintainers.

@kushal @moshez @yossarian @jugmac00 Even if they do, there's other ... coping strategies .. for signatures (multiple maintainers on PyPI, shared keys, ...)

(I'm not _happy_ with gpg etc, but yet another article saying "pgp sux" isn't helping The Discourse much if no alternatives are presented)

@moshez @yossarian @jugmac00 In this case, yes I'm the only one. In other things I maintain there's more than one maintainer, so I suppose Debian has a system to encode that "these N keys are valid for Y packages".
@yossarian I never even realised PyPi had PGP support.

@yossarian
PGP signatures: worse than useless.

There, I fixed it for you.

As tools GPG (and PGP) are simply unusable by anyone but fastidious zealot pedants. And thus always used wrong.

@glyph

@gpshead @yossarian @glyph I still have hope to fix the usability of tools/services in future. I know most of my friends totally lost all hope :)
@kushal @gpshead @yossarian the world needs more good signing and security tools, but the sooner you abandon GPG (and OpenPGP more broadly) the sooner you can start building those ;-). There's really nothing worth salvaging here.

@glyph @gpshead @yossarian I beg to differ on that point. @[email protected] & I are building https://tumpa.rocks/

Here is an example where we can have better UX focused tools in the #OpenPGP land.

Tumpa

Tumpa is a usability-minded OpenPGP desktop application that makes key management and smartcard controls easy and usable for everyone.

@kushal
Is any of that something you could build atop signify instead?
@glyph
@eichin @glyph I guess for the signing part, yes. We also have #age with hardware support (and I love that).
@kushal @eichin if you're doing stuff with age and pgp in the same process don't you have to have some kind of magnetic containment field so they don't touch and cause a matter/antimatter annihilation reaction
@kushal @eichin I am seriously curious though: what about your problem domain makes GnuPG a desirable component? Why not throw its broken overcomplexity in the trash, define what you want your app to do in terms of user security guarantees, and then build it on top of a good backend or a novel cryptographic construction instead? I know "roll your own crypto" is bad, but it's a cut above "wrap gnupg"

@glyph @[email protected] Something that works for both encryption & signing. Bonus is that I can use the same for my ssh. Works out of my Yubikey, means no secret on disk. My mutt setup mostly works :)

I can see the pain points and hoping to improve them by creating newer things with usability in mind.

On the software side, most of the applications I install separately uses OpenPGP to sign the artifacts, including @fedora and also #debian.

@gpshead @yossarian @glyph this take always makes me imagine a civil engineer standing next to wet concrete, checking her watch and muttering "nobody has time for this shit"
@Octarine @gpshead @yossarian … why? GPG isn’t slow, it’s bad
@glyph @gpshead @yossarian after writing and deleting a few pithy but vague drafts, the point I would like to reach is about engineering ethics. Big blocks of the tech world are not commissioned safely, merely appropriated from the fastidious pedant community. That community is a Venn diagram of many circles most of which are not labelled "engineer" at all. PGP is not fit for purpose and yet I am using PYPI rather than tagging it out for my org until controls are in place. That gives me pause.
@Octarine @gpshead @yossarian sorry, I cannot parse this at all. PGP is not used for anything on PyPI, so I don’t see how it is related to your use of PyPI. I don’t know what “tagging it out” means. I don’t know what controls you’re referring to, or why you haven’t put them in place.

@glyph @gpshead @yossarian my concern is that installing a PGP signed package on PyPI without verifying it is analogous to a safety feature of hazardous industrial plant that is routinely bypassed at the point of use because it isn't fit for purpose.

Bypassing safety features rather than "tagging out" plant from service and removing the feature is a failure of engineering ethics, because having users bypass safety features (who don't always have a minimum qualification) is a horrible precedent.

@Octarine @gpshead @yossarian OK, I have some sense of where you're coming from now, but I think you might have a distorted view of how PyPI integrated with GPG. People interested in actual safety here are using other solutions, doing things like pinning hashes and deterministic builds. The GPG stuff was never a safety feature, just a tacked-on afterthought intended to provide infrastructure for someone to *later* implement a safety feature. Nobody ever did, and now it's being removed.

@yossarian Great post, thanks for sharing the numbers!

I did similar analysis about signing packages (JAR files) in Clojure ecosystem with similar results a few years ago. Unfortunately I didn't write it up in detail, but basically the tooling was broken and majority of the public keys were undiscoverable.

Since it was clear that nobody was systematically verifying the signatures, I stopped signing my own packages.

@yossarian Thank you for writing this. I found the link just after I did a release on PyPI with `twine upload --sign` :) I guess I am one of those last remaining one.

@yossarian as someone who had to maintain my old job's pgp stuff because banks still use pgp to encrypt files sent to us, I very much hate it

Has any progress been made on replacing pgp for signing? Git also has this problem where there really should be something better to do signature verification but I haven't really seen anything

About commit signature verification - GitHub Docs

Using GPG, SSH, or S/MIME, you can sign tags and commits locally. These tags or commits are marked as verified on GitHub so other people can be confident that the changes come from a trusted source.

GitHub Docs
@yossarian
So they're just doing Debian cosplay?
@ian @yossarian no, we stopped surfacing signatures in the UI more than half a decade ago, and today https://blog.pypi.org/posts/2023-05-23-removing-pgp/
Removing PGP from PyPI - The Python Package Index Blog

PyPI has removed support for uploading PGP signatures with new releases.

Onboard maintainers to the release process · Issue #561 · pypa/build

Our release process requires that maintainers have their PGP key listed in https://pypa-build.readthedocs.io/en/stable/installation.html, and preferably have their key signed by one of the other ma...

GitHub