Comment by sowbug
1 year ago
The research article cited in the announcement is titled "PGP signatures on PyPI: worse than useless."
That's the issue. Pretending there is a security solution in place is worse than being upfront that there is none. If you look down and notice that your seatbelt is actually made out of angel hair pasta, you might drive more carefully. Hopefully you'll also get a better car.
But they're not "worse than useless", that article was wrong. PGP/GPG are without doubt problematic, they have weak points (like use of SHA-1, some keys that could not be located, and terrible UI) but they are not worse than having no traceability of the package at all between the author and PyPI.
The system guaranteed that a key signed a package. That was its entire utility.
At best, it defeated plausible deniability for package maintainers who had avowed public keys, but then somehow signed a bad package. This wouldn't have stopped the malware from getting onto your system. It only would have led you to the hapless (but honest) package maintainer.
It didn't stop someone who is not you from generating a PGP key for Richard WM Jones, signing malware, uploading to PyPi, and then disappearing back under the rock where they live. And if you believe this system is not useless, then you also believe that at least one person out there was not dissuaded from installing that malware because "Hey, someone named Richard WM Jones went through the trouble of signing it!"
As is often the case, the value of this system depends on your threat model. I'm not too worried about someone going rogue from the tiny population of people who were using PGP correctly. But I am worried about using a platform that claimed to have signing infrastructure, when that infrastructure had no meaningful checks on who was signing.
> they are not worse than having no traceability of the package at all between the author and PyPI.
Except that they are: PGP does not give you this kind of identity relationship. The most it can give you is an association to a key ID, which is (1) brute-forceable, and (2) not strongly bound to any actual user or machine identity.
The only thing worse than an unsecured scheme is an insecure scheme that lulls users into a false sense of security and authenticity. PGP signatures on PyPI are the latter.
>The most it can give you is an association to a key ID, which is (1) brute-forceable
This is false. That would mean brute forcing a 160 bit SHA-1 hash. That is not possible.
2 replies →
It's like the larger holy war against self-signed certificates in TLS. They are strictly better than plaintext but there is software that will prefer a plaintext connection to self-signed TLS.
Unverifiable security is not "strictly better" than plaintext.
25 replies →
I think another thing with pgp is that it's in this awkward place where it's bad enough that few people use it, but good enough that it prevents someone from making an alternative.
Nobody's making a PGP alternative because a major part of what makes PGP bad is that it tries to be a generic solution to every problem, when in practice signing and encryption workflows are incredibly domain-specific.
People are continuously creating better tools for domains that historically saw PGP usage. To name a few: Signal for short-form messaging, age for file encryption, signify/minisign for artifact signing.
The article is closer to a blog post than a multiple authors peer reviewed research paper published in a high impact journal.
That's because it is a blog post. It isn't advertised as anything else.
I wonder if the domain being `blog.pypi.org` tipped them off?