Not trying to diminish broader trends in the software landscape, but this thread was talking about big established gnu software (like GPG) and newer rust based alternatives (like sequoia mentioned in the recording). This choice seems fairly unmediated by large corporations. Probably has more to do with the popularity of rust and how well they market, but the license doesn’t seem to matter that much to people.
I'm not worried it might be the case. I'm certain that ubuntu and everyone else replacing gnu stuff with rust MIT stuff is done with the sole purpose of getting rid of copyleft components.
If the new components were GPL licensed there would be less opposition, but we just get called names and our opinions discarded. After all such companies have more effective marketing departments.
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.
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.
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.
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.)
I don't think cargo is much better in that respect. It's what happens when instead of a decent standard library and a few well established frameworks you decide that every single little thing must be a separate project.
“The user can choose between starting their new policy on the first day of employment, the first day of the fiscal year, on a specific date, or some number of days after their prior policy expires. If they choose the first day of the fiscal year, the user must specify when their company’s fiscal year starts. If they choose a specific date they must choose a date that is after the first business day of the next month and no later than December 31st of the year that month belongs to. If the user specified some number of months after their current policy expired the user must provide a policy number and the number of days no less than 1 and no more than 365.”
Type validation can help with some of that but at some point it becomes way easier to just use imperative validation for something like this. It turns out that validating things that are easy is easy no matter what you do, and validating complex rules that were written by people who think imperatively is almost impossible to do declaratively in a maintainable way.
reply