OK, fair point regarding bespoke PKI on Windows/Mac being more common. I do agree with that. I'll amend my statement to: PGP is by far the most common standard for server-side software distribution. I'll also quickly add that I agree that git signing is worthless as currently implemented.
I have read your blogpost and I agree that PyPI had unused and useless PGP support. I also agree that signatures are a waste of time when the client tooling does not verify by default. However, this is not true for the Linux distro packaging ecosystem where approximately all downloads have their signatures verified. Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
Don't mistake me as a defender of PGP-the-standard. I have absolutely no opinion on its cryptography. I would happily use minisign or any other tool that used only modern cryptography to produce signatures. As a distributor of software though, I don't really get to decide how to sign, I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
> PGP is by far the most common standard for server-side software distribution.
This is probably true, for Linux. Windows does its bespoke PKI thing with Authenticode; OpenBSD uses signify[1].
> Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
This is a fair point! But I'll point something important out: these platforms are essentially using PGP as a dumb key encapsulation format; they benefit (correctly!) from being able to pre-baked rings of trusted distribution keys. The fact that they use PGP for this is an implementation quirk, one that has materially negative consequences[2].
It's not easy for them to switch, but all of these platforms would be well (better) served by switching from PGP to signify, minisign, or similar.
> I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.
Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
I agree that RedHat and Debian use OpenPGP mostly for its signature only and do not rely on any Web of Trust or other infrastructure for key distribution in the basic case. As a side-note just for fun:
They distribute their public keys on their own web infrastructure, so it's effectively TOFU. In your criticism of PyPI, you rightly pointed out that keys are useless unless pushed to a publicly-known key server because they aren't discoverable for users, which leads to ~no one verifying installs. I agree with this for PyPI, but in Postgres' case, if you do not have their key pulled locally, installs will fail by default. This means that users do generally install keys locally (actually they typically install the repo RPMs which configures local repositories as well as installs keys), even if the discovery mechanism isn't enforced by yum. My point here is that ecosystems without the ability to pre-bake rings of trust can still result in ~all downloads being verified as long as the client tooling defaults to the correct thing. pip not doing so is the main reason why OpenPGP signing never caught on in the Python ecosystem.
But yes, I agree: A modern day dpkg and rpm could swap to something with safer cryptography rather easily without changing anything about distribution. OpenPGP is a lot of bloat for their needs.
> Out of curiosity: which government standards? I'm not aware of a US Gov't standard that mandates PGP; this would be very valuable to know.
I don't believe any mandate OpenPGP specifically. I was more trying to get across that many institutions mandate FIPS 140-2/3, and current implementations (like on RHEL) complain if signatures are not present in their expected format. Because OpenPGP is my only choice for signing yum infrastructure and RPMs, it's a de-facto government standard today.
That's for developers. But if I'm a user of Debian and I download and install the ISO, I am not part of the web of trust. I'm trusting Debian as a central authority to ship me a valid keyring.
Which is fine; the centralization here makes sense, for the same reason I trust Microsoft to give me Windows updates or McDonalds to give me fries and burgers. But it's no more "web of trust" than either of those examples.
My guess is that there are a lot more "signature verification events" on Linux that pull from a deb or yum repository than there are on Windows servers, both because the mean server in terms of global usage seems to be Linux (though not the median, I'd think?) as well as because it seems like Linux folk rely an awful lot more on distribution repositories than Windows server users download things. Happy to be corrected if anyone has real numbers, though. My feelings are informed by my company's download statistics which may not be representative.
I have read your blogpost and I agree that PyPI had unused and useless PGP support. I also agree that signatures are a waste of time when the client tooling does not verify by default. However, this is not true for the Linux distro packaging ecosystem where approximately all downloads have their signatures verified. Until you convince RedHat and Debian to move their packaging and repository formats to another standard, PGP will remain very relevant for production server software.
Don't mistake me as a defender of PGP-the-standard. I have absolutely no opinion on its cryptography. I would happily use minisign or any other tool that used only modern cryptography to produce signatures. As a distributor of software though, I don't really get to decide how to sign, I am at the mercy of government and ecosystem standards, and as a result no other signature scheme is close to the level of use that PGP has for enterprises that run server-side software.