Debian is basically the reason we didn't delete PGP signature support in 2018, because in theory some handful of Debian packages might be better off with this support.

In practice I think the handful of packages that this happens on isn't particularly meaningful or valuable, and in my experience what happens when Debian finds a new key signing packages is.. highly variable. I've seen them just disable signatures when a new key shows up (on major packages even), I've seen them just blanket copy whatever the new key is, I've seen them look at release notes for what the new key is. In one or two cases I've seen them actually track down the project and ask for verification of the new key.

To me, the PGP support in Debian's uscan feels more like security theater than actual security controls, given my experience with the varied responses to a new release being made by a different key.

Even just as a fancy checksum I think it has some value, and I think it does serve some security goals. I feel like this article also kind of amounts to listing off a bunch of threats that aren't being properly mitigated, and it doesn't really do a good job of separating which threats are not mitigated because of intrinsic deficiencies in PGP from which threats are not mitigated because other parts of the system haven't even made an attempt to mitigate the threat.

And then there's the third category, which is "threats which could be mitigated but PGP makes this hard so people tried and gave up." Just giving up entirely doesn't seem like the right reaction here, and that seems to be what the PGP downers are advocating.

There are other efforts underway to mitigate these threats (which could be subject to their own critiques, but let's not get into that here) but PGP has had 20 years to prove its utility in this area and it has resoundingly proved that it (A) does not address the threats it purports to and (B) introduces tons of confusing complexity into processes which are not benefiting from it.

Let me restate that: it is not free to continue supporting PGP. It has a tremendous cost both in its own maintenance and its opportunity cost. Every moment spent attempting to mitigate its fundamentally broken design is a moment that could instead be put into designing something new, that works properly and doesn't require dragging around the massively bloated corpse of 1999-era cryptographic engineering.

Also, if you really want a "fancy checksum" for verifying package installs, there's already a better feature in pip that actually works and is well-supported: https://pip.pypa.io/en/stable/topics/secure-installs/

If people want checksums, it seems like it would be better for everyone around to just use checksums? If you just want to make sure that some file hasn't changed, that's a much better primitive for that then signatures.

To me the most interesting part of the article is whether or not the current signatures are even capable of being validated or not, which the answer to that is > 50% of them are not, and those are of the people who care enough in the last 3 years to still be using this undocumented feature.

Is it possible to build a secure signing system ontop of GPG/PGP? Sure. But doing that requires working around or eschewing so many features from it that you might as well just use the base primitives yourself rather than being tied to GPG/PGP.