| |
| ▲ | 15 hours ago | parent | next [-] | | [deleted] | |
| ▲ | LtWorf 21 hours ago | parent | prev | next [-] | | Well python discarded signing entirely so that's one way to solve it :) | | |
| ▲ | woodruffw 21 hours ago | parent [-] | | 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.) | | |
| ▲ | LtWorf 20 hours ago | parent [-] | | Being signed by some entity which is not the author is hardly more effective. (I think you already know this as well) | | |
| ▲ | woodruffw 20 hours ago | parent [-] | | 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. | | |
| ▲ | LtWorf 19 hours ago | parent [-] | | Not really, uploading via trusted publishers I don't own any private key, as you probably know having implemented it yourself I presume. | | |
| ▲ | woodruffw 18 hours ago | parent [-] | | 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. | | |
| ▲ | LtWorf 18 hours ago | parent [-] | | 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. | | |
| ▲ | woodruffw 18 hours ago | parent [-] | | 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. | | |
| ▲ | kuschku 7 hours ago | parent | next [-] | | 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. | |
| ▲ | LtWorf 17 hours ago | parent | prev [-] | | I think you are conflating a CI runner I don't really control with my machine? | | |
| ▲ | woodruffw 17 hours ago | parent [-] | | 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. | | |
| ▲ | some_furry 16 hours ago | parent [-] | | 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. | | |
| ▲ | woodruffw 16 hours ago | parent [-] | | 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.) |
|
|
|
|
|
|
|
|
|
|
| |
| ▲ | cpach 21 hours ago | parent | prev [-] | | GPG is indeed deprecated. Most people have never heard of it and never used it. | | |
| ▲ | woodruffw 21 hours ago | parent | next [-] | | 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.) | | | |
| ▲ | IshKebab 19 hours ago | parent | prev [-] | | 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. | | |
| ▲ | tptacek 18 hours ago | parent [-] | | They allow some kind of nerd to claim that, but nobody who nerds out on cryptography defends PGP. Cryptographers hate PGP. |
|
|
|
