This feels pretty unsatisfying: something that’s been “considered harmful” for three decades should be deprecated and then removed in a responsible ecosystem.

(PGP/GPG are of course hamstrung by their own decision to be a Swiss Army knife/only loosely coupled to the secure operation itself. So the even more responsible thing to do is to discard them for purposes that they can’t offer security properties for, which is the vast majority of things they get used for.)

Well python discarded signing entirely so that's one way to solve it :)

Both CPython and distributions on PyPI are more effectively signed than they were before.

(I think you already know this, but want to relitigate something that’s not meaningfully controversial in Python.)

Being signed by some entity which is not the author is hardly more effective.

(I think you already know this as well)

It is, in fact, signed by the author. It's just a PKI, so you intermediate trust in the author through an authority.

This is exactly analogous to the Web PKI, where you trust CAs to identify individual websites, but the websites themselves control their keypairs. The CA's presence intermediates the trust but does not somehow imply that the CA itself does the signing for TLS traffic.

Not really, uploading via trusted publishers I don't own any private key, as you probably know having implemented it yourself I presume.

Trusted Publishing doesn’t involve any signing keys (well, there’s an IdP, but the IdP’s signature is over a JWT that the index verifies, not an end signature). You’re thinking of attestations, which do indeed involve a local ephemeral private key.

Again, I must emphasize that this is identical in construction to the Web PKI; that was intentional. There are good criticisms of PKIs on grounds of centrality, etc., but “the end entity doesn’t control the private key” is facially untrue and sounds more like conspiracy than anything else.

Conspiracy in what way? Can you explain?

On my web server where the certificate is signed by letsencrypt I do have a file which contains a private key. On pypi there is no such thing. I don't think the parallel is correct.

With Let’s Encrypt, your private key is (typically) rotated every 90 days. It’s kept on disk because 90 days is too long to reliably keep a private key resident in memory on unknown hardware.

With attestations on PyPI, the issuance window is 15 minutes instead of 90 days. So the private key is kept in memory and discarded as soon as the signing operation is complete, since the next signing flow will create a new one.

At no point does the private key leave your machine. The only salient differences between the two are file versus memory and the validity window, but in both cases PyPI’s implementation of attestations prefers the more ideal thing with respect to reducing the likelihood of local private key disclosure.

No? With let's encrypt the certificate is rotated, but the private key remains the same, and importantly, let's encrypt never gets to see it, and anything is logged.

I said “typically” because Let’s Encrypt doesn’t control key rotation: the issuance managing client (like Certbot) does.

But AFAICT, Certbot has rotated private keys automatically on reissuance since at least 2016[1]. There’s no reason not to in a fully automated scheme. I would expect all of the other major issuing clients to do the same.

[1]: https://community.letsencrypt.org/t/do-new-private-keys-get-...

I think you are conflating a CI runner I don't really control with my machine?

I mean, it’s an ephemeral VM that you have root on. You don’t own it, but you control it in every useful sense of the word.

But also, that’s an implementation detail. There’s no reason why PyPI couldn’t accept attestations from local machines (using email identities) using this scheme; it’s just more engineering and design work to determine what that would actually communicate.

It might be worthwhile for someone to do this engineering work; e.g., to make attestations work even for folks that use platforms like Codeberg or self-hosted git.

Yeah, completely agreed. I think there's a strong argument to be made for Codeberg as a federated identity provider, which would allow attestations from their runners.

(This would of course require Codeberg to become an IdP + demonstrate the ability to maintain a reasonable amount of uptime and hold their own signing keys. But I think that's the kind of responsibility they're aiming for.)

Can you provide a source this? To my understanding, the GnuPG project (and by extension PGP as an ecosystem) considers itself very much alive, even though practically speaking it’s effectively moribund and irrelevant.

(So I agree that it’s de facto dead, but that’s not the same thing as formal deprecation. The latter is what you do explicitly to responsibly move people away from something that’s not suitable for use anymore.)

Ah. I meant in the de facto sense.

I would be very much surprised if GPG has ever really achieved anything other than allowing crypto nerds to proclaim that things were encrypted or signed. Good for them I guess, but not of any practical importance, unlike SSH, TLS, 7Zip encryption, etc.

They allow some kind of nerd to claim that, but nobody who nerds out on cryptography defends PGP. Cryptographers hate PGP.

This doesn't explain why he decided to WONTFIX what is obviously a parser bug that allows injection of data into output through the headers.

But werner at this point has a history of irresponsible decisions like this, so it's sadly par for the course by now.

Another particularly egregious example: https://dev.gnupg.org/T4493