If you have ever downloaded Python from python.org and verified the download using a PGP signature, you are going to want to know about PEP 761. Accepted in November 2024, this proposal formally deprecates PGP signatures for CPython artifacts and sets the course for Sigstore to become the sole signing method going forward. With Python 3.14.0 shipping in October 2025 as the first release without PGP signatures, this is no longer a theoretical change -- it is live. It is a quiet but meaningful shift in how Python's security infrastructure works, and it affects anyone who verifies CPython builds as part of their workflow.
What Are CPython Artifact Signatures, and Why Do They Matter?
When the CPython team releases a new version of Python, they publish downloadable artifacts -- source tarballs, binaries, and installers -- on python.org. Alongside those files, they also publish cryptographic signatures that allow you to verify two things: that the file came from an authorized Python release manager, and that the file has not been tampered with since it was signed.
This matters to downstream integrators: Linux distribution maintainers, package managers like Homebrew and pyenv, build systems, and CI pipelines that fetch CPython from source. For these users, verifying signatures is a critical part of a secure software supply chain.
Until recently, CPython provided two signatures for every artifact: one using PGP (Pretty Good Privacy) and one using Sigstore. PEP 761 changes that by beginning the process of removing PGP from the equation.
Artifact signing sits at a conceptual boundary that is easy to overlook: it is the point where social trust gets encoded into mathematical trust. You trust that the release manager is who they claim to be. A cryptographic signature translates that belief into a verifiable, machine-readable assertion. Every design decision in a signing system is fundamentally a decision about where to place the boundary between human judgment and automated verification -- and how much fragility you are willing to accept at that boundary.
PGP placed that boundary at the individual: one person, one key, one responsibility. Sigstore moves it to an institution: an identity provider, a certificate authority, a transparency log. Neither is inherently more secure. The question is which model degrades more gracefully when something goes wrong -- and for a volunteer-maintained project like CPython, "going wrong" often just means someone getting busy, losing a device, or stepping away for a few years.
What Is PGP and Why Is It Being Dropped?
PGP has been around since 1991 and has long been the standard tool for signing software releases. At its core, PGP works by having a trusted party -- in this case, a Python release manager -- generate a long-lived private key, guard it carefully for years, and use it to sign artifacts. Anyone who wants to verify a signature obtains the corresponding public key and checks it against the file.
The problem is that "guard it carefully for years" is harder than it sounds. Python release managers are responsible for multiple CPython releases over a period of seven or more years. That is a long time to maintain the security of a private key, keep it backed up, prevent it from being compromised, and manage the operational overhead of rotating or revoking it if something goes wrong. This is all done by volunteers.
Beyond the operational burden, PGP's security model and user experience have been the subject of sustained criticism from security researchers and practitioners for many years. Key discovery is cumbersome, key expiration is often mishandled, and the web-of-trust model does not translate well into automated build pipelines. None of this means PGP is useless, but it does mean that better options now exist.
Enter Sigstore
Sigstore was designed specifically to solve the problems that make PGP awkward for software artifact signing. It has been adopted by PyPI, npm, Homebrew, GitHub, and other major ecosystems, and since Python 3.11.0, CPython has been publishing Sigstore signatures alongside PGP signatures for every release.
The core difference is how keys are handled. Instead of requiring a release manager to generate and maintain a long-lived private key, Sigstore uses short-lived, ephemeral keys that are tied to a verifiable identity via OpenID Connect. In practice, this means a release manager clicks through an OAuth login during the release process -- the same kind of login they already perform for GitHub or Google -- and Sigstore handles the rest. No key to store, no key to lose, no key to rotate after seven years.
Sigstore's transparency log (Rekor) provides a public, append-only record of all signatures, making it possible to audit signing activity in ways that PGP simply does not support. Offline verification is also supported via .sigstore bundle files, addressing one of the concerns raised during the PEP's discussion period.
| Dimension | PGP | Sigstore |
|---|---|---|
| Key lifecycle | Long-lived (7+ years per release manager) | Short-lived, ephemeral per signing event |
| Identity binding | Web of trust / manual key exchange | OpenID Connect (GitHub, Google, etc.) |
| Audit trail | None built-in | Public transparency log (Rekor) |
| Offline verification | Supported natively | Supported via .sigstore bundle files |
| Release manager burden | Generate, store, protect, rotate keys | OAuth sign-in during release process |
| Ecosystem adoption | Legacy standard, declining use | PyPI, npm, Homebrew, GitHub |
The Centralization Trade-Off
Sigstore's advantages are real, but they come with a trade-off that a feature comparison alone does not capture. PGP, for all its operational pain, is decentralized by design. A release manager generates their own keys, and verification requires nothing more than the public key and a local GPG installation. There is no external service that must be online, no certificate authority that must remain trustworthy, and no transparency log that must stay funded and operational.
Sigstore introduces dependencies on centralized infrastructure: Fulcio (the certificate authority), Rekor (the transparency log), and the OpenID Connect identity providers -- currently Google and GitHub -- that bind human identities to signing certificates. If Fulcio is down during a release, signing cannot happen. If Rekor is unavailable to a verifier that has not cached the bundle locally, online verification fails. And if an identity provider is compromised, an attacker could theoretically obtain a valid signing certificate for a release manager's identity.
The Sigstore project addresses these concerns through what its designers describe as "trusted but verifiable" infrastructure. The transparency log is append-only and publicly auditable, so a compromised certificate authority cannot issue a fraudulent certificate without leaving a permanent record. The root of trust is managed by a distributed set of community keyholders through TUF (The Update Framework), not by any single organization. And offline verification is fully supported via .sigstore bundle files, which contain everything needed to verify a signature without contacting Sigstore services at all.
The PEP's author, Seth Larson, deliberately avoided framing PGP as insecure. The motivation is ergonomic, not a claim that PGP's security model is broken. CPython's development already depends on the security of GitHub and Google accounts for source control and identity management, so trusting those same providers for signing certificates does not introduce a fundamentally new dependency -- it formalizes one that already exists.
This is the most substantive objection, and it deserves a direct answer rather than a dismissal. Sigstore does centralize trust infrastructure that PGP left distributed. If Fulcio is compromised, a fraudulent certificate can be issued. If Rekor goes down, online verification fails. If Google or GitHub's OIDC implementation is breached, signing identities are exposed. These are real dependencies, not theoretical ones.
Three factors tip the balance. First, the centralization is verifiable: Rekor's transparency log means any misissued certificate leaves a permanent, publicly auditable record -- unlike PGP, where a stolen key produces signatures indistinguishable from legitimate ones. Second, the dependency already exists in practice: CPython's source control, CI, and release infrastructure already run on GitHub. Trusting GitHub for signing does not add a new failure mode; it makes an implicit dependency explicit and auditable. Third, and often overlooked, PGP's decentralization was largely fictional for CPython's use case. In practice, a handful of release managers each held a single key for seven-plus years with no external monitoring. The "distributed" model was really a collection of isolated single points of failure, each one invisible until something went wrong.
The honest answer is that both models have single points of failure. The difference is whether those failure points are monitored and auditable, or silent and invisible.
Through the Attacker's Lens
One way to sharpen the comparison between PGP and Sigstore is to stop asking "which is more secure?" and start asking "what does each system force an attacker to do?" The threat models are different in kind, not just in degree, and understanding those differences is what separates a policy opinion from an informed one.
Steal or compromise a single private key that may sit on one person's laptop, USB drive, or hardware token for seven or more years. The attack is patient and targeted. If successful, it is invisible -- no public log records the signing event, and the forged artifact is indistinguishable from a legitimate one until the compromise is independently discovered.
Compromise an OIDC identity provider (Google, GitHub) or the Fulcio certificate authority to obtain a valid signing certificate. If successful, the forged signing event is permanently recorded in Rekor's transparency log. The attacker must now also suppress or explain away a public audit trail. Detection is not guaranteed, but the evidence is durable and machine-readable.
Neither system prevents compromise. The difference is what happens afterward. PGP optimizes for independence: no external party can interfere with signing or verification, but no external party can detect abuse either. Sigstore optimizes for accountability: every signing event is recorded, but that accountability depends on the integrity and availability of shared infrastructure.
This distinction matters for how you think about the transition. If your threat model is a nation-state adversary with the resources to compromise identity providers, Sigstore's centralized dependencies may concern you -- though even in that scenario, Rekor's transparency log creates evidence that PGP never would. If your threat model is the far more common case of key mismanagement, lost hardware, or a volunteer who moves on without revoking their credentials, Sigstore's ephemeral key model eliminates the attack surface entirely.
PEP 761's dynamics echo an earlier ecosystem-wide transition: the web's move from self-managed SSL certificates to Let's Encrypt. For years, sysadmins generated their own keys, purchased certificates from commercial CAs, and managed renewal calendars manually. Let's Encrypt automated all of it through ACME, using short-lived certificates and centralized infrastructure -- and drew the same objections Sigstore faces now: dependency on a single authority, trust in a centralized service, loss of "sovereignty" over one's own cryptographic identity.
The result was not a weaker web. Encryption coverage went from roughly 40% of page loads in 2015 to over 80% within a few years, precisely because automation lowered the barrier. Security improved not because the cryptography got stronger, but because the human operational burden dropped low enough for universal adoption. PEP 761 is a bet that the same dynamic will hold for software artifact signing: that a system volunteers can use without thinking about it will produce better security outcomes than a system that demands years of careful key hygiene from unpaid contributors.
What PEP 761 Actually Specifies
The PEP is precise about the timeline and scope of the change.
PGP signatures are being deprecated starting now, with discontinuation tied to release managers rather than release numbers. The reason for this is practical: PGP keys are associated with individual release managers, not with versions of Python. Rather than abruptly dropping PGP mid-stream, the PEP uses the natural transition point when a new release manager takes over a new Python version.
Python 3.14 is the first version affected. Hugo van Kemenade, who manages 3.14, is not required to generate or maintain a PGP key. Python 3.14.0 shipped on October 7, 2025, making this the first CPython release where PGP signatures are no longer provided. All previous stable releases -- 3.13, 3.12, 3.11, and so on -- will continue to receive PGP signatures until they reach end-of-life. Python 3.13, for example, will carry PGP signatures through its end-of-life in October 2029. Existing PGP signatures on python.org will remain available permanently and will not be removed.
The PEP includes a mechanism for the Python Steering Council to delay discontinuation if extraordinary circumstances require it. If that happens, all active release managers would be required to provide PGP signatures for their covered releases, and the discontinuation would be pushed to the next new release manager.
The Gordian Knot: Why Dual-Signing Had to End
One of the more interesting arguments in PEP 761 is strategic rather than technical. While CPython provided both PGP and Sigstore signatures simultaneously -- as it did from Python 3.11.0 onward -- neither signers nor verifiers had a compelling reason to change their behavior. The PEP describes this dynamic as an incentive knot: a self-reinforcing cycle where each side waits for the other to move first.
Verifiers had no reason to adopt Sigstore because PGP continued to work and there was no expectation it would go away. Signers could not drop PGP because verifiers still appeared to rely on it. Verifiers never tested Sigstore, so the maintainers of verification tooling could not learn about or improve verifier use-cases. And because almost everyone involved is a volunteer, doing the work to adopt a new process while the old one still functions feels like low-priority effort.
The PEP's solution is deliberate: remove the fallback. By ending PGP availability at a natural transition point -- when a new release manager takes over a new Python version -- the incentive knot gets cut. Downstream verifiers are forced to adopt Sigstore, which in turn makes it easier for other upstream projects to migrate to Sigstore-only signing, creating what the PEP describes as a positive feedback loop of adoption across the ecosystem.
The dual-signing problem is a case study in what economists call a coordination failure. Every individual actor is behaving rationally -- verifiers stick with what works, signers provide what verifiers expect -- and yet the collective outcome is suboptimal for everyone. The system is stuck in a Nash equilibrium where no single party has an incentive to move first.
PEP 761's approach is essentially a forcing function applied by the party with the most leverage: the upstream project itself. By removing the fallback, CPython transforms the game from one of voluntary coordination to one of sequential adaptation. This is the same logic behind protocol deprecation in web standards (TLS 1.0/1.1 sunsets), browser feature removals (Flash), and certificate authority migrations. The pattern is consistent: when backward compatibility prevents forward progress, the party closest to the root of the dependency tree has to move first and accept the short-term friction.
What This Means If You Verify CPython Downloads
If you are verifying CPython artifacts using PGP today, you have time to migrate. All releases up through the 3.13 series will continue to carry PGP signatures until they go end-of-life. For 3.14 and beyond, only Sigstore signatures will be available.
The recommended tool for verification is the sigstore Python package, or cosign if you prefer a pre-compiled binary that does not require an existing Python installation.
Here is an example of verifying a CPython artifact using cosign:
# Download the artifact and its Sigstore bundle
wget https://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz
wget https://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz.sigstore
# Verify using cosign
./cosign verify-blob \
--new-bundle-format \
--certificate-oidc-issuer 'https://accounts.google.com' \
--certificate-identity '[email protected]' \
--bundle ./Python-3.13.0.tgz.sigstore \
./Python-3.13.0.tgzOffline verification is also supported by adding --offline and providing a pinned root of trust file, which can be obtained from the Sigstore root-signing repository on GitHub.
Verification using the sigstore Python package is equally straightforward and does not require a separate binary download:
# Install the sigstore package
pip install sigstore
# Verify using the Python sigstore client
python -m sigstore verify identity \
--bundle Python-3.14.0.tgz.sigstore \
--cert-identity [email protected] \
--cert-oidc-issuer https://github.com/login/oauth \
Python-3.14.0.tgzIf your existing workflow pins artifacts to SHA-256 checksums after PGP verification, Sigstore supports that pattern directly. You can verify using only the checksum without downloading the artifact itself, which is useful for environments where the artifact has already been fetched and stored.
Full documentation for verifying CPython artifacts with Sigstore is available at python.org/downloads/metadata/sigstore/.
Where Linux Distributions Stand
The transition is not equally smooth for everyone. During the PEP's discussion period, maintainers from several Linux distributions raised practical concerns about readiness. Fedora's Python maintainer noted that Fedora verifies PGP signatures of Python tarballs during package builds but faced blockers with Sigstore adoption, including the number of dependencies in the Python sigstore client and the need for offline verification support.
At the time of the PEP discussion, Cosign was available in Alpine Linux's package repositories but not yet in Debian, Fedora, or Gentoo. This matters because many distributions build packages in isolated environments where pulling binaries from external sources like GitHub releases is undesirable or prohibited. Experimental Debian packaging of Cosign has since begun, with successful tests verifying CPython 3.14 alpha tarballs in Debian containers.
Offline verification was another concern. Distributions like Gentoo ship signatures inside packages to enable "build from source" workflows where network access is not guaranteed during the build. Sigstore supports this through bundle files and a pinnable root of trust, but the tooling ecosystem is still catching up with packaging for these workflows.
Steve Dower, a CPython core developer, noted during the PEP discussion that PGP signatures for Windows and macOS Python builds were already redundant with the native OS-level code signing used on those platforms. The Linux distribution use-case is the one where the PGP-to-Sigstore migration requires the most effort.
Infrastructure developments are narrowing the gap. Sigstore's Rekor v2 -- a redesigned transparency log that is cheaper to operate and simpler to maintain -- reached general availability, with per-shard URLs replacing the monolithic endpoint and TUF-based key distribution handling client upgrades automatically. Cosign v3 now defaults to the standardized bundle format and supports TUF-distributed root material, reducing the friction that earlier distro packagers encountered. And Trail of Bits, funded by the OpenSSF, has been preparing rekor-monitor for production use, making it straightforward for package maintainers to receive alerts when signing events occur under their identity -- a capability that has no PGP equivalent.
The distro packaging gap reveals a recurring tension in open source security: the organizations with the strictest verification requirements (Linux distributions building in air-gapped environments) are often the slowest to adopt new tooling, because their constraints are the most demanding. This is not resistance to change -- it is the natural consequence of environments where "pull a binary from GitHub" is an unacceptable build dependency. The PEP's timeline -- allowing legacy releases to carry PGP signatures until end-of-life while cutting over on the next release series -- is designed to give these environments years of runway, not weeks.
The Bigger Picture
PEP 761 is part of a broader shift in how the open source ecosystem thinks about supply chain security. The same pressures that led Python to adopt Sigstore -- the need for auditable, automated, low-friction artifact signing -- are pushing other major projects in the same direction. When CPython moves, it carries weight. By removing PGP as a comfortable fallback, the PEP is designed to accelerate Sigstore adoption across downstream tooling and other upstream projects that have been waiting to see how things shake out.
The timing is not coincidental. CPython now ships SBOMs (Software Bills of Materials) with releases, Python 3.14 introduced multiple headline features (free-threaded builds, t-strings, deferred annotation evaluation), and the Python Software Foundation has navigated significant financial pressures including declining revenue and PyCon operating at a loss. In this context, PEP 761 is also a sustainability decision: reducing the operational surface area that volunteer release managers must maintain, at a time when the demands on their time are increasing.
For the vast majority of Python users, none of this changes anything about how you install or use Python. For those who maintain build pipelines or distribution packaging that depends on CPython artifact verification, now is a good time to start testing your Sigstore verification workflow so you are ready well before the transition affects you.
Workload Identity: What Comes After Personal Signing
The current Sigstore setup still ties signing to individual release managers through their personal email addresses and OIDC identity providers. Hugo van Kemenade signs Python 3.14 artifacts as [email protected]. This is a massive improvement over PGP key management, but it still means that downstream verifiers need to know which release manager is responsible for which Python version and update their verification configuration when release managers change.
The next evolution is workload identity. Instead of signing being tied to a person, it would be tied to the build infrastructure itself. If CPython's release process runs on GitHub Actions, the expected signing identity would become something like gh/python/release-tools/... -- a stable, machine-readable identity that never changes when release managers rotate. This removes the last piece of human-specific configuration from the verification pipeline.
CPython is not there yet. The macOS and Windows release processes do not currently use hosted build platforms that support OpenID Connect and Sigstore's workload identity flow. But the groundwork is being laid. PEP 740, which specifies how PyPI can serve Sigstore attestations using Trusted Publishers, is provisionally accepted. As more of CPython's release infrastructure moves to hosted CI platforms, the transition to workload identity becomes increasingly practical.
For downstream verifiers, this means the Sigstore migration is not a one-time change. It is the first step in a trajectory that leads to fully automated, infrastructure-backed artifact verification -- where the identity of the build system, not the identity of the person who clicked "release," is what gets verified.
Zoom out far enough and PEP 761 traces a three-phase evolution in how software identity works. Phase one: you trust a person (PGP -- a release manager holds a key). Phase two: you trust a person, verified by an institution (Sigstore today -- a release manager authenticates via an identity provider). Phase three: you trust a process, verified by an institution (workload identity -- the build pipeline authenticates itself). Each phase removes a layer of human involvement from the trust chain.
The philosophical question this trajectory raises is whether fully removing human identity from artifact signing is an unqualified improvement, or whether it trades one class of risk (human error, key mismanagement) for another (infrastructure compromise, institutional capture). The answer likely depends on the threat model you are designing for -- and the honest acknowledgment that no signing system eliminates trust; it only redistributes it.
gh/python/release-tools), not a person's email. Stable across release manager rotations.The Verification Gap No One Measured
There is a question that runs beneath the entire PEP 761 discussion, and it is one that no one involved has been able to answer with data: how many people were verifying PGP signatures for CPython artifacts in the first place?
The honest answer is that no one knows. Python.org serves download files and signature files from the same infrastructure, but download counts for .asc files were never published alongside tarball download counts. Steve Dower's observation during the PEP discussion -- that PGP signatures for Windows and macOS builds were reinstated after removal not because anyone demonstrated they were being used, but because people complained -- suggests the answer is: fewer than you might expect.
This matters because the framing of PEP 761 as a migration from PGP to Sigstore can obscure the more interesting possibility: that Sigstore might increase the total number of verifiers, not just swap out the tooling for existing ones. PGP verification requires enough background knowledge to find, fetch, and trust the right public key -- a nontrivial barrier even for experienced engineers. Sigstore's verification flow, by contrast, requires knowing a release manager's email address and running a single command. If the practical result of PEP 761 is that more CI pipelines and build systems start verifying CPython artifacts at all, the security improvement is larger than any comparison of cryptographic properties would suggest.
Security infrastructure that no one uses provides zero protection, regardless of how strong its cryptographic foundations are. The real competition is not PGP versus Sigstore -- it is verification versus no verification. If PGP's operational complexity meant that the overwhelming majority of downstream consumers never verified CPython artifacts at all, then the status quo was not "PGP-protected downloads." It was unverified downloads with a PGP signature sitting next to them on the server, untouched. The strongest argument for PEP 761 might not be any property of Sigstore itself. It might be that Sigstore is easy enough that verification becomes something that happens by default rather than by heroic effort.
Post-Quantum Cryptography and the Next Migration
PEP 761 solves a current problem, but it also creates a future one that deserves attention now. Sigstore's entire signing and verification chain -- Fulcio's certificate issuance, Rekor's transparency log, and the ephemeral signing keys themselves -- relies on classical cryptographic algorithms. Specifically, Sigstore uses elliptic curve cryptography for signing and verification. These algorithms are vulnerable to attack by a sufficiently powerful quantum computer.
The timeline for that threat is debated, but the direction is not. NIST finalized its first set of post-quantum cryptographic standards in August 2024 (ML-KEM, ML-DSA, and SLH-DSA), and governments worldwide have set migration deadlines between 2030 and 2035. The Sigstore project published its own post-quantum roadmap in 2025, stating that it wants to enable signing with post-quantum keys as soon as possible and adopt post-quantum algorithms in its services once reliable implementations are available in Go's standard cryptographic library. Trail of Bits has begun work on cryptographic agility for Sigstore's core services, and Red Hat's Emerging Technology Security Team has started prototyping post-quantum signing for Sigstore through the Trusted Artifact Signer project.
None of this is production-ready yet. The practical implication for PEP 761 is that by centralizing CPython's signing infrastructure on Sigstore, the Python ecosystem has also centralized its post-quantum migration path. When Sigstore transitions to quantum-resistant algorithms -- and it will need to -- every project that depends on Sigstore for verification will need to upgrade its verification clients. Under the old PGP model, each project could independently choose when and how to adopt post-quantum cryptography. Under Sigstore, the migration becomes coordinated, which is either an advantage (one transition instead of hundreds) or a risk (one bottleneck instead of distributed adaptation), depending on how smoothly the Sigstore project executes it.
Post-quantum algorithms come with trade-offs that matter for Sigstore's architecture. ML-DSA signatures and public keys are an order of magnitude larger than their elliptic curve equivalents -- kilobytes instead of tens of bytes. For a transparency log like Rekor that records every signing event, this represents a meaningful increase in storage and bandwidth costs. The Rekor v2 redesign, with its tile-based architecture and per-shard URLs, was not designed with post-quantum payload sizes in mind. Whether the current architecture scales gracefully under post-quantum workloads is an open engineering question that the Sigstore team will need to address before the transition.
Under the old PGP model, each project could independently adopt post-quantum algorithms on its own timeline. A security-critical project could move early; a less sensitive one could wait. Under Sigstore, every dependent ecosystem transitions together, on Sigstore's schedule. If Sigstore is slow to adopt post-quantum algorithms -- perhaps because Go's crypto library lags behind -- every project that depends on it inherits that delay.
The independent-migration scenario sounds good in theory, but the PGP era provides the counter-evidence. PGP's "independence" meant that in practice, almost nobody migrated to anything. Decentralized migration requires every individual project to independently evaluate, implement, and test new cryptographic algorithms -- work that volunteer-maintained projects rarely have the capacity to do. Sigstore centralizes that burden on a funded team with institutional backing and a published roadmap. The risk is a single bottleneck; the benefit is that the migration happens at all. Given the history of cryptographic transitions in open source (SHA-1 took over a decade to sunset), a coordinated migration led by a dedicated team is more likely to produce timely results than hundreds of independent projects each finding their own path.
Sigstore Beyond Code: ML Models and the Expanding Trust Surface
PEP 761 frames Sigstore adoption as a CPython release process change, but the scope of what Sigstore is being asked to secure is expanding well beyond code artifacts. In April 2025, the OpenSSF, Google, NVIDIA, and HiddenLayer released version 1.0 of the model-signing project, built on top of sigstore-python, enabling machine learning models to be signed and verified using the same Sigstore infrastructure that secures CPython releases. NVIDIA's NGC container registry began supporting Sigstore-signed attestations in mid-2025. Maven Central adopted Sigstore in January 2025. The pattern is clear: Sigstore is becoming the default trust layer not just for code packages but for a widening category of software and AI artifacts.
This expansion has implications for CPython's signing infrastructure that the PEP does not address. When Sigstore served a handful of major open source projects, the risk of its public-good instance becoming a bottleneck or a high-value target was manageable. As Sigstore's transparency log grows to encompass container images, ML models, and artifacts from every major package registry, the infrastructure becomes both more critical and more attractive to adversaries. The Rekor transparency log is append-only and publicly auditable, which is a strength for detection -- but if the volume of entries grows by orders of magnitude, the cost of monitoring that log for unauthorized signing events grows with it.
There is an asymmetry in how trust infrastructure scales. When a signing system is decentralized (as PGP was), each new adopter adds their own infrastructure and bears their own risk. When a signing system is centralized (as Sigstore is), each new adopter increases the value of the shared infrastructure while increasing the blast radius of its failure. The more ecosystems that depend on Sigstore, the more consequential a compromise of Fulcio or Rekor becomes -- and the more pressure falls on the relatively small team that operates the public-good instance. CPython's decision to adopt Sigstore is sound on its own merits. But CPython does not exist in isolation, and the collective risk profile of Sigstore's public infrastructure is a function of every project that depends on it, not just the ones you are evaluating individually.
Who Pays for Public-Good Signing Infrastructure?
Sigstore's public-good instance -- the Fulcio certificate authority, the Rekor transparency log, and the associated monitoring and oncall infrastructure -- is operated with a 99.5% availability SLO. That level of reliability does not maintain itself. The infrastructure runs on donated compute, is maintained by a dedicated team, and is governed through the OpenSSF (Open Source Security Foundation), which is itself a project of the Linux Foundation. Funding comes from a mix of corporate sponsors, foundation grants, and in-kind contributions.
PEP 761 explicitly depends on the continued operation of this infrastructure. If Fulcio goes down during a CPython release, the release cannot be signed. If Rekor becomes unavailable, online verification fails for anyone who has not cached bundle files locally. The PEP addresses this with offline verification support and by noting that CPython's development already depends on the availability of GitHub and Google. But there is a difference between depending on services that have independent business models sustaining them (Google, GitHub) and depending on a public-good service that relies on the continued goodwill and funding of its sponsors.
This is not a hypothetical concern. Open source security infrastructure has a recurring pattern of being underfunded relative to its criticality. The OpenSSL Heartbleed vulnerability in 2014 revealed that one of the internet's foundational security libraries was maintained by a handful of people with minimal funding. The XZ Utils backdoor in 2024 demonstrated that supply chain pressure can be applied to under-resourced maintainers. Sigstore is better positioned than either of those projects -- it has institutional backing, full-time maintainers, and an active governance structure. But the question of long-term sustainability for public-good infrastructure is never fully answered. It is managed, not solved.
Organizations that depend on Sigstore for critical verification workflows should evaluate whether running a private Sigstore instance makes sense for their environment. Sigstore's components are open source and can be self-hosted, which removes the dependency on the public-good infrastructure entirely. For organizations with strict availability requirements or regulatory constraints, a private instance provides the same cryptographic guarantees without the shared-fate risk of the public service.
This is where all the threads converge. Thread 1 asked where trust boundaries belong. Thread 5 traced the trajectory from personal to institutional trust. Thread 6 showed how centralizing trust concentrates risk. And now we face the question that sits beneath all of them: who sustains the institutions we are being asked to trust?
The pattern in open source security is not that critical infrastructure gets attacked and fails. The pattern is that critical infrastructure gets built, works quietly, becomes load-bearing for the entire ecosystem, and then slowly loses funding and maintainer attention because the absence of visible failure creates the illusion of self-sufficiency. Sigstore is not there yet. But every signing system CPython has ever used -- including PGP -- was "well-supported" at the point of adoption. The relevant question is not whether Sigstore is well-supported today. It is whether the funding and governance model can sustain institutional trust at the scale the ecosystem is building toward. That is a political and economic question, not a cryptographic one -- and it is the one that matters most for the long-term viability of everything PEP 761 enables.
You fetch CPython tarballs programmatically and verify them before building. This is the most directly affected category.
You package CPython for downstream users and need verification tooling that works in constrained build environments. Your timeline is longer but your constraints are tighter.
You care about supply chain integrity and may have compliance requirements around artifact provenance. The centralization question matters to you.
You download Python from python.org or use a version manager. For you, PEP 761 changes nothing about your daily workflow -- but understanding it changes how you think about trust.
Key Takeaways
- PEP 761 deprecates PGP signatures: Accepted in November 2024, the PEP formally begins the process of removing PGP signatures from CPython release artifacts.
- Sigstore replaces PGP: CPython has provided both PGP and Sigstore signatures since Python 3.11.0. Sigstore uses short-lived keys tied to identity providers like GitHub and Google, requiring far less ongoing maintenance from volunteer release managers.
- Python 3.14 shipped without PGP: Released on October 7, 2025, Python 3.14.0 is the first CPython release without PGP signatures. All stable releases through 3.13 continue to receive PGP signatures until end-of-life.
- Existing signatures are preserved: All PGP signatures already on python.org will remain available permanently. Nothing is being removed retroactively.
- Centralization is a deliberate trade-off: Sigstore depends on centralized infrastructure (Fulcio, Rekor, OIDC providers), but mitigates this through public auditability, community-managed root of trust, and offline verification support.
- The threat models differ in kind: PGP makes compromise invisible; Sigstore makes it auditable. Neither prevents attack, but Sigstore produces durable evidence that PGP does not.
- Rekor v2 and Cosign v3 are narrowing adoption gaps: Redesigned infrastructure and standardized bundle formats are reducing friction for distro packagers, and
rekor-monitorenables proactive compromise detection. - Linux distro tooling is catching up: Cosign packaging in major distributions has been the primary adoption blocker. Debian packaging progress continues, and offline verification workflows are maturing.
- Workload identity is the next step: The long-term trajectory moves signing from personal release manager identities to build infrastructure identities, removing human-specific configuration from verification pipelines entirely.
- The real win may be more verification, not better verification: If PGP's operational complexity meant few downstream consumers verified artifacts at all, Sigstore's lower barrier to entry could increase the total volume of verification across the ecosystem -- a larger security improvement than any cryptographic comparison suggests.
- Post-quantum migration is centralized now: By standardizing on Sigstore, the Python ecosystem has also centralized its future migration to quantum-resistant cryptography. The Sigstore project has published a post-quantum roadmap, but production-ready implementations are still in progress.
- Sigstore's trust surface is expanding fast: ML model signing, Maven Central, and container registries are adopting Sigstore alongside code package ecosystems. The public-good infrastructure is becoming more critical -- and more attractive as a target -- with each new adopter.
- Public-good infrastructure requires ongoing investment: Sigstore's availability depends on continued funding and maintenance through the OpenSSF. Organizations with strict uptime requirements should evaluate self-hosted Sigstore deployments.
- Migrate now: If your workflow depends on PGP verification of CPython artifacts, begin testing Sigstore-based verification using
cosignor thesigstorePython package.