Yes. As the post says: well-designed signing schemes need to be misuse resistant.
(And to be clear: it's not the "spec" they're failing to implement. The breakages here indicate that people aren't generating strong keys or doing signing operations correctly with the `gpg` CLI; poor design and documentation there is absolutely the tool's fault.)
This has been a problem with so many cryptographic systems over the years. For various reasons they prefer to be backwards compatible over being secure. As the best practices shift, the default values of these applications stay the same.
I understand why, to a certain extent. If your defaults change and people are expecting the old values it could break existing scripts and tool chains. For most applications this argument makes sense, but for security focused tools I think this is a mistake. Defaults should always represent best practices, and people who want specific flags should specify them.
That's not something to get hung up on: what matters is the semantics, not whether or not each bit is defined.
Here's a good example, in 3.2:
> Also note that when an MPI is encrypted, the length refers to the
plaintext MPI. It may be ill-formed in its ciphertext.
What does this mean? Is the MPI encrypted separately (how?), or something else? Why would you even mention it being "ill-formed" in its ciphertext (it has to be, unless something has gone very wrong), much less use a wiggle phrase like "may"?
If you dig further through the spec, you find under 5.5.3 that MPIs can be "secret" MPIs, which are apparently encrypted with a passphrase that gets munged through a KDF defined by an S2K identifier. But this is inexplicable under the "secret packet" part of the spec, not the MPI part. And it does nothing to address the second ambiguity.
Here's a place (5.2.3.1) where the spec is unambiguous, but forces clients to be ambiguous:
> If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error.
This is the exact opposite of what ecosystems like X.509 do; it's a pointless source (perfectly well-specified!) variance on the client side.
As the post says: PGP has been discouraged on PyPI for years, because using it correctly is difficult. The goal here is not to try and carve out the "good" bits, but to drive home that even the remaining users (who were expected to be experts, given that it's no longer advertised) are continuing to use it insufficiently for its stated goals.
Perhaps a good way forward is to come up with a positive incentives, like already exists with the various badges for CI success, test coverage, documentation, valid HTML5, etc. There could be a service that verifies that PGP key can be fetched and the latest pypi version verified. To avoid putting the burden of hosting on you, perhaps you could provide a python script which takes the package name and allows people to self-validate?
A bunch of utilities which can handle "signing" with some sort of a key isn't a solution. That's not solving the trust problem, which is the actual hard part of GPG.
GPG isn't hard to use. It has quirks, but it's not hard - programmers should be able to figure it out.
Trust management is hard and no one has solved trust management well. It doesn't make one iota of difference how file signing is done, what matters is whether it can be done in a way which makes the scope, degree and path of trust clear in a way the user can action.
Hence my question: because the way we solve "trust" on the internet is "trust a megacorp". The global HTTPS system is based on whichever CAs are shipped in our browsers. And those CAs create global trust - they can issue certificates which say that anything, anywhere is totally who they say they are. Just the Root Certificate Authority process (which isn't bad, but it is just "hey guys, totally trust us").
> GPG isn't hard to use. It has quirks, but it's not hard - programmers should be able to figure it out.
I've been using GPG for roughly a decade, and I don't think I can consistently reproduce the basic commands I need from memory. I've lost track of the number of times I've corrupted my TTY by forgetting `--armor`, much less the number of times GPG has helpfully "guessed what I mean" in the wrong way.
At one point, I had at least 3 different copies of my key bundle on different keyservers. I wouldn't be able to tell you which one is the right one; I can count on a single hand the number of emails I've received encrypted to the right subkey (and on two hands the number of emails encrypted to any key of mine).
> Just the Root Certificate Authority process (which isn't bad, but it is just "hey guys, totally trust us").
This isn't true in a useful sense: the CA/B standards are pretty transparent, and the Web PKI mandates transparency (through things like CT) in a publicly auditable way. You can see (and verify) exactly what every CA is doing in the Web PKI, at all times.
I don't think PGP really solves any of these problems either, not for the vast majority of users outside of a fairly small group of PGP enthusiasts. PGP has a complex model and perhaps that's actually its weakest point – going "back to basics" would probably be a good thing.
In the meanwhile, there's lots of use cases that could benefit from easier and more straight-forward signing. I had simply given up on signing anything in git because I just couldn't get it to work (it worked, and then it didn't, and then I fixed it with some effort, and then it broke again in obscure ways, and then I gave up) until git supported OpenSSH signing, which I've been using since the day it was committed without problems.
(And to be clear: it's not the "spec" they're failing to implement. The breakages here indicate that people aren't generating strong keys or doing signing operations correctly with the `gpg` CLI; poor design and documentation there is absolutely the tool's fault.)