It's not a language feature, but I wanted to point out a new aspect of how Python is released: releases are now signed with Sigstore[1], producing a certificate and signature for each source distribution/build in the release table[2].
This is intended to supplement the current PGP signatures, giving Python distributors (and the packagers themselves) a similar degree of authenticity/identity without needing to perform PGP keyring maintenance.
For anyone browsing on Android and confused, the sigstore website has a major design issue hiding the menu button on some devices. You need to scroll the page to the right: https://github.com/sigstore/sigstore-website/issues/132
‘di said it, but to emphasize: with sigstore, there is no key management whatsoever. The keys in question are ephemeral and never leave your machine; the entire idea of the project is to bind an identity (like an email or GitHub username) to short-lived signing certificates.
So in addition to getting the file from python.org over HTTPS, you get a certificate attesting that sigstore automatically checked that it was released by the people who owned python.org? What security does this add?
PGP has a web-of-trust aspect, allowing people to trust people. What is the point of something doing automated verification of identity, on top of the one done for HTTPS certificate issuance?
The certificate specifically demonstrates that the <release-manager>@python.org identity signed the artifact.
So there's a) no long-lived private key for them to lose (because it's never stored after signing) and b) a consumer doesn't need to find the right key PGP ID, verify (somehow) that that key ID is associated with a given release manager -- they can just trust that the release manager is in control of their @python.org identity.
Additionally, with PGP, you have no idea if your private key is being used somewhere else to generate valid signatures maliciously. With Sigstore, in order for the signature to be valid, it must be published in a transparency log, which is continuously monitored. So in the event of if the key/identity is compromised, the identity owner can be made aware immediately and the signature revoked.
Not the people who own python.org, but the CPython release maintainers.
They’re different groups of people, which points to one of the potential benefits to sigstore verification here: people who download CPython from python.org can now additionally verify that the artifact was not tampered with on the server. They can, furthermore, mirror the artifact and its signing material on their own. In short, TLS provides delivery authenticity while sigstore providers publisher authenticity.
Sigstore has no idea who the publishers should be, they do automated verification based on a domain or GitHub account. The person owning the GitHub org might be some admin, just like with the domain. The automated process doesn't know and doesn't care.
That is where the concept of policies come in: an actual deployment of sigstore for verification purposes would establish the artifact’s identities via another mechanism. That mechanism is going to depend on the sigstore deployment: in the context of most package indices, for example, it probably makes sense to have the verification map to the index’s account metadata, package metadata, etc. That could, in turn, be made into a public commitment via a TUF repository.
However, that complexity does not apply to simple cases like the CPython one: for this case, you can verify that the identity matches the one of the public email identities of the CPython release team. This is no more complex that PGP identity verification, and is much more resilient (since anybody can publish a claimant key for an identity in PGP).
You're comparing Sigstore with the log and assuming ultimate trust in their verification process and CA to GPG without the web-of-trust. This is obviously apples-to-oranges.
You also linked to this random python.org HTTPS page which contains the list of people you are supposed to expect to have signed the Python releases. If this is the root of trust... it might has well have had PGP fingerprints.
The truth is that you login with OIDC and Sigstore signs your artifacts, giving you an attestation that the owner of that email/GitHub/... identity made that artifact, and publishes that to a persistent log. This makes the whole thing great for automation (both of publishing and verifying), but claiming that this adds to security is false.
Their Security Model page clearly outlines the limits of their system and is consistent with my characterization https://docs.sigstore.dev/security/:
> If an OIDC identity or OIDC provider is compromised, Fulcio might issue unauthorized certificates
> If Fulcio is compromised, it might issue unauthorized certificates
You have to trust OIDC providers, you have to trust the CA, and the presence of logs only allows those people to notice unauthorized issuance, not end users.
I think we're going in circles, because I've identified specific ways in which this adds to the security model that self-custodial PGP keys cannot:
* Sigstore uses short-lived keys and short-lived certificates, eliminating an entire common risk class where maintainers accidentally disclose their signing keys. This property alone eliminates the single largest source of illegitimate signing events in ecosystems like Windows software.
* The logs in question are public CT logs. In other words: anybody can audit them for unauthorized issuance, including the legitimate publishing identity. It's not particularly useful for the end (installing) user to audit the log, but it was never claimed that they would find it useful.
For the specific case of CPython, you're missing the point: CPython is an easy case, since the email identities of the release managers are well-known facts that can be cross-checked across python.org, GitHub, etc. Python.org is not currently a root of trust for sigstore, but it is for PGP (again, because anybody can claim an identity in PGP).
There are, of course, limitations. But these limitations are no strictly worse than trusting CA and IdP ecosystems that you're already trusting, which makes them strictly better than mystery meat PGP keys.
You're just replacing a "mystery meat" PGP key with a "mystery meat" email address or OIDC handle. As you point out, committing to one of those can easily be done by posting it on python.org, GitHub, etc with the major difference that PGP fingerprints are cryptographically tied to an identity rather than require a third-party like Sigstore to attest that the person had control of it at some point in the past.
It is also much more likely that someone managed to click one link in a developer's inbox once to complete the automated Sigstore verification, rather than they managed to steal their PGP keyring and passphrase.
I am not a fan of having to trust in developer's key-management abilities but this just shifts the problem very slightly, at significant cost.
The single advantage is obvious: this allows easy automated signing and verification, allowing enterprises to easily check boxes in their supply-chain-security checklist. This is valuable in itself, and I am all for automation, but I don't know why we have to claim that it is "more secure".
> PGP fingerprints are cryptographically tied to an identity rather than require a third-party like Sigstore to attest that the person had control of it at some point in the past.
A PGP fingerprint is tied to a PGP key, which is tied to a claimed identity. Anybody can claim to be you, me, or the President of the United States in the PGP ecosystem. Some keyservers will "verify" email-looking identities by doing a clickback challenge, but that's neither standard nor common.
In theory, you trust PGP identities because of the Web of Trust: you trust Bob and Bob trusts Sue, so you trust Sue. But it turns out nobody actually uses that, because it's (1) unergonomic and doesn't handle any of the normal failure cases that happen when codesigning (like rotation), and (2) it's been dead because of network abuse for years anyways[1].
> It is also much more likely that someone managed to click one link in a developer's inbox once to complete the automated Sigstore verification, rather than they managed to steal their PGP keyring and passphrase.
That's not how Sigstore does email identity verification; it uses a standard interactive OAuth flow. Those aren't flawless, but they're significantly better than a secret URL and fundamentally avoid the problem of secure key storage. Which, again, is actually where most codesigning failures occur.
OAuth flow is even worse, if you find someone's browser open and click the link, it will complete as long as they are currently logged into GitHub/Gmail/whatever provider. I am not claiming that key management is easy or foolproof, but when this is what we're comparing to...
And again, you don't have to use web-of-trust. It is there, which is an advantage. If you don't/can't use that, you can find a PGP fingerprint on a random HTTPS page, which will be just as easy to copy-paste as the list of email addresses you showed me a couple posts up... with the advantage that I can use them for verification directly, rather than involving third-party authorities.
> OAuth flow is even worse, if you find someone's browser open and click the link, it will complete as long as they are currently logged into GitHub/Gmail/whatever provider. I am not claiming that key management is easy or foolproof, but when this is what we're comparing to...
And the same can be said for PGP keyholders. There are very, very few threat models in which an open, logged-in computer is not a "game over" scenario (which is also why most password managers and authentication agents don't consider it a case worth guarding against). In other words: Sigstore is no worse than PGP key management in this manner, but is better in the other ways that matter.
Looking up PGP fingerprints on random HTTPS pages is not a scaleable or ergonomic solution, and not one that has ever succeeded. Remember: that is the status quo with both CPython and Python package distribution, and there is no evidence that either had gained any meaningful amount of adoption (either by packages or end users). The goal here is to enable users to sign packages without doing the things they've demonstrated they won't do.
(Also, we've focused on email identities. A separate goal is to allow GitHub Actions identities, which will require no interaction from a user's browser and has a threat model coextensive with the CI environment that many Python packages are already using to build and publish their distributions.)
> with the advantage that I can use them for verification directly, rather than involving third-party authorities.
I'm not sure what you mean by "third-party authorities" here. As a verifier, your operations can be entirely offline: you're verifying that the file, its signature, and certificates are consistent, that their claims are what you expect, and (optionally) that the entry has been included in the CT log. That latter part is the only online part, and it's optional (since you can opt for a weaker SET verification, demonstrating an inclusion promise).
> PGP has a web-of-trust aspect, allowing people to trust people
Must be great for the 5 people on the planet that maintain a personal web of trust with PGP while the rest of us just run whatever "curl|gpg --import" command the download page tells us to run, thus adding zero security on top of https.
The alternative is this, you get a nifty certificate from Sigstore that allows you to be sure that "somerando@outlook.com" has indeed authored the lib you depend on. How do you check if that's what you want? How much security do you get from knowing that the email is definitely correct for a person you know nothing about?
Anyone can generate a hash. Signing with a private key means that only the owner of that private key was able to generate a given signature. Singing with a private key which was bound to a known identity via a signing certificate proves that only that identity was in possession of the signing key, during a very short window.
In this specific case, we can say that the artifacts in question were verifiably signed by owner of the <release-manager>@python.org identity.
That's the point of the certificate authority and transparency log: it makes the public key known by publicly binding it to a verifiable identity.
A hash verifies integrity, but has no way to demonstrate any relationship to a signing identity. Signing is not just about integrity, but also being able to say _who_ generated the signature.
* You generate a keypair and use it to sign your Python installer (SP)
* Authority creates a signature of your public key (SA) and puts the whole thing in transparency logs (SP + SA)
* End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your signature SP, therefore can trust your software
Why not just use a hash instead:
* You generate a hash of your Python installer (HP)
* Authority creates a signature of your hash (SA) and puts it in transparency logs (H + SA)
* End users can check SA because they trust authority, can check SA is in transparency logs, therefore can trust your hash, therefore can trust your software
What matters is that ultimately the contents of your software are signed by the Authority and a commitment of that is in logs. Why add this level of keys, that can't possibly be trusted since they are ephemeral?
This proposed scheme lacks individual publishing identities, which are desirable. The goal here isn't just to churn out random signatures; it's to be able to associate specific identities (such as a person, GitHub repository, or specific CI workflow) with the production of an artifact.
It also requires the user to trust the signer to do proper secret generation, which is weakens the scheme. With Sigstore, the entire CA and CT infrastructure can fail or be compromised, but the certificates (and the ephemeral keys that they bind to) remain sound. That too is desirable, which is why the TLS PKI ecosystem is the way it is.
Edit: To be clear, the PGP equivalent for your scheme would be "trust Joe Public to sign for everyone on PyPI, he's reliable." If you can see why that doesn't work, you should also be able to see why your alternative to Sigstore won't work.
The certificates remain sound? What does that mean? Those certificates are never to be reused (ephemeral). Do you mean the signature remains valid and secure?
And whether the CA signs "identity information + public key" or "identity information + software hash", I don't see the different in "identities", no matter what that means to you.
Please, give a concrete example of information that is available/verifiable in one scheme and not the other. You both keep saying vague things like "it lacks identities" or "there's a binding" etc and I really don't see it.
The idea behind sigstore is to enable an end user (which, for CPython, might be someone who intends to build it from source for inclusion in a package manager) to verify that the artifact is the same one produced by a trusted entity, not just the same one downloaded from a server. A strong cryptographic hash only provides the latter.
The keypair is bound to a public identity via OIDC. That’s where the authenticity comes from; modulo a breach in GitHub’s IdP, you can be confident that the keypair corresponds to a signing action performed by the GitHub identity (either username or repository).
> The keypair is bound to a public identity via OIDC
It is not "bound" to anything cryptographically. Sigstore checks that you own the OIDC account, and if yes, it signs your public key and puts it in the log. Why not just sign your software's hash and put it in the log, "binding" it as you say?
This is true, but only because a cryptographic binding to the OIDC JWT would be meaningless. Fulcio could conceivably hash the JWT and add it as another certificate extension, but I don't see why it would (since nobody is expected to "burn" the JWT by publishing it after expiry).
> Why not just sign your software's hash and put it in the log, "binding" it as you say?
That's exactly what it's doing. Is the objection you have solely to the fact that it can be done with short-lived keys?
It’s very close to the existing PKI ecosystem for TLS: the CA is presented a possession proof for the locally held private key, and mints a signing certificate for it.
There is no singular “root certificate”: there’s a trust root for the CA, a separate root for the transparency log, etc.
Nope. The private key is generated within the client each time a signing event occurs, and that's what is used to sign the artifact. It doesn't come from the certificate.
The certificate just binds the public key to the identity at a given point in time, in a public way. This certificate is generated every time you sign something, and is put in the transparency log.
This is intended to supplement the current PGP signatures, giving Python distributors (and the packagers themselves) a similar degree of authenticity/identity without needing to perform PGP keyring maintenance.
[1]: https://www.sigstore.dev/
[2]: https://www.python.org/downloads/release/python-3110/