> You would need to make it so that there's a setting in an account so an API key is useless to publish without a signed commit.
That’s the “easy” part. The hard part is determining what constitutes a valid PGP identity, as well as inheriting all of the baggage that comes with PGP (including things that nobody wants to deal with, like revocation).
And again: this would be explicitly forcing users into a known bad signing mechanism, one that only applies to git. Trusted publishing as-implemented does not have these problems.
It’s a pretty well known blog, from a pretty well known security company.
I would also go as far as to say that “PGP is bad and should not be used for greenfield projects” is not a remotely controversial opinion in applied cryptography circles. Likewise, it is not controversial in those circles to assert that PGP is more or less the opposite of current technology for digital signatures.
Some more helpful links by generally recognized authorities[1][2]. You’ll note that each of these is more than a few years old at this point; PGP’s deficiencies are very well trodden.
There is no meaningful sense in which PGP is “canceled”, except in the kind of shitpost sense I would use in a talk slide.
Open alternatives exist, are better, and have been better for well over a decade at this point. No significant risk is posed to “open tech” by doing things better than PGP can possibly offer us.
There is a strict sense in which PGP does not remain on the table for you, because PyPI does not (and will not, on this developer’s clean conscience) ever support PGP for authentication :-)
As said in adjacent threads, PyPI intends to add support for other OIDC providers once they give us the claims we need. Whether or not you choose to use it is ultimately up to you; normal API tokens will continue to work.
It still is, because I can have my CI use it to determine whether to publish a PyPI package.
Nice try though.
This is definitely a new low for Python. The main issue is just that it was a Microsoft-only launch. All the rest is just window dressing.
It's a good reminder about the Pylance situation in Visual Studio Code. Microsoft tricked people into using closed source. https://ghuntley.com/fracture/
Plus "giving up on long term PGP" doesn't really apply here. You can add and remove GPG keys on GitLab every day if you like.
I have respect for those who still have a private key to go with a public key they created 10+ years ago. I don't, except maybe on the encrypted hard drive of a dead laptop on which I haven't gotten around to doing data recovery.
It feels like that these two blog posts (and the one by lacorta) are the only ones that anti-PGP folks on HN could find on internet. There are far more tutorials on the use of PGP than on its problems (mostly around email encryption, which isn’t relevant here).
Decentralized trust is a very good idea. PGP provides useful functionalities around that. Keybase was a good project, but sadly was acquired and has since stopped.
The alternatives proposed are great in narrow use cases, but aren’t really replacements.
> It feels like that these two blog posts (and the one by lacorta) are the only ones that anti-PGP folks on HN could find on internet. There are far more tutorials on the use of PGP than on its problems
They're the ones that come up because (1) they're good, (2) they're increasingly "old" (indicating that these problems are not newly identified), and (3) they're reputable sources.
Besides, technical volume doesn't mean anything (and certainly doesn't imply quality): there are innumerable copies of the Anarchist's Cookbook on the Internet, and the sheer number of volumes doesn't make their contents any less likely to blow your hand off.
The problems identified are not unique to email encryption; email encryption stands out as a punching bag for PGP's failures because of how consistently PGP fails to provide meaningful security while the rest of the world has moved on. Notably, all of the problems related to PGP signatures in emails are shared by codesigning with PGP.
> Decentralized trust is a very good idea. PGP provides useful functionalities around that. Keybase was a good project, but sadly was acquired and has since stopped.
This hasn't been true for years (PGP's strong set and web of trust are dead, in thanks part to poor format design that enabled trivial resource attacks on keyservers. And the second part contradicts the first: the thing that made Keybase useful was that it centralized and made (mostly) work a bunch of things that don't work in "bare" PGP (such as actual proofs of identity/account possession).
If you're just looking for signs of consensus that issue describes why the Go pgp package is deprecated - it is very critical of pgp. Interesting read too.
That’s the “easy” part. The hard part is determining what constitutes a valid PGP identity, as well as inheriting all of the baggage that comes with PGP (including things that nobody wants to deal with, like revocation).
And again: this would be explicitly forcing users into a known bad signing mechanism, one that only applies to git. Trusted publishing as-implemented does not have these problems.