Preserve expectations across a Python release

To avoid breaking downstream verifiers, the expectations for verification materials availability SHOULD NOT be changed during a feature release’s lifecycle.

Release managers, not releases

The discontinuation of PGP signatures doesn’t necessarily have to happen on a “release manager boundary”; a new Python release could be a potential boundary.

Because the primary motivation for deprecating PGP is ergonomics, deciding to drop PGP for one release while a release manager still has obligations to provide PGP signatures for other releases for multiple years isn’t much savings of effort.

A new release manager also represents a new PGP public key that downstream verifiers need to adopt. By choosing to make the change during this period, this minimizes the breakage to a place in downstream maintenance where a change will already be necessary.

Gordian knot of signing methods and verifiers

CPython providing both PGP and Sigstore signatures concurrently creates a “Gordian knot” where verifiers are disincentivized to migrate to a new signature method due to the continued and expected availability of an existing signature method, thus propagating the apparent demand for maintaining the existing signature method.

This situation slows down the adoption of new signature methods like Sigstore for both signature-producing projects and signature-verifying ecosystems by not creating a “need” to automate and integrate the signature method into verifier tooling.

By changing the expectation of what future signature methods will be available, the incentive-knot can be broken by spurring the adoption of the new signature method in downstream tooling. This change to verifier tooling also makes other upstream projects able to migrate to publishing only Sigstore signatures, resulting in a positive feedback loop of adoption.

Deprecation and discontinuation of PGP signatures

This PEP deprecates PGP signatures for future CPython releases and recommends verifiers to adopt Sigstore to verify CPython artifacts as an alternative to PGP.

This PEP also removes the expectation that PGP signatures be published by future release managers that don’t already maintain a stable Python release. At the time of writing this would be Hugo van Kemenade, as 3.14 is the next Python version without a stable release.

Releases which already have a stable release (3.13, 3.12, 3.11, etc) are not affected and will continue to provide PGP signatures for artifacts until they are end-of-life. All existing PGP signatures will continue to work as expected.

Delaying discontinuation of PGP signatures

This PEP provides a mechanism to delay the discontinuation of PGP signatures from active and upcoming CPython releases in case of extraordinary circumstances. Deprecation of PGP signatures can’t be changed without a superseding PEP.

The Steering Council MAY at a future date after this PEP’s acceptance decide to delay the discontinuation of PGP signatures to a future CPython release. If the Steering Council decides to delay the discontinuation of PGP signatures then all active release managers MUST provide PGP signatures for their covered CPython artifacts for the remainder of their tenure as a release manager. This includes all steps required to do so, such as generating a new PGP key and publishing their identity to python.org.

The discontinuation of PGP signatures then is automatically scheduled for the next release manager without a stable release, to be highlighted in the Steering Council decision.

Continue publishing PGP signatures indefinitely

Being a release manager is already a difficult, time-consuming, and long-term commitment that is typically done on a volunteer basis. Thus we see removal of PGP key management duties as a step towards reducing burnout and stress of future release managers and improving the sustainability of CPython.

Support for offline verification

During the pre-PEP discussion, there was a question of whether offline verification was supported by Sigstore. Using a Sigstore bundle (.sigstore) file, Sigstore clients support verifying the artifact completely offline.

Using offline verification with Sigstore requires disabling root of trust updates and “pinning” a root of trust in a file to use during verification.

Pinning a root of trust means signatures made after a new root of trust is established would no longer be able to verify using a “pinned” previous root of trust. New roots of trust are expected to be rare events, such as when the root of trust is compromised, and in this case verifiers would want signatures to fail to verify.

Offline verification also makes revocation checks impossible, but this is similar to PGP’s model where revocation of keys requires an online lookup.

Barring rare events like root of trust compromise, using offline verification with Sigstore doesn’t impose additional operations requirements to verifiers.

Support for a pre-compiled executable for verification

During discussion there were requests for a pre-compiled executable that could be used for verifying Sigstore bundles without needing to either install a Go build toolchain to build sigstore-go from source or already have a working Python installation for sigstore-python.

Cosign is another Sigstore project that provides pre-compiled standalone binaries and supports verifying bundles offline:

# Download Cosign
wget https://github.com/sigstore/cosign/releases/download/v2.4.1/cosign-linux-amd64

# For offline verification, also need the Root of Trust. Can be grabbed
# from GitHub at: https://github.com/sigstore/root-signing/blob/main/targets/trusted_root.json
wget https://raw.githubusercontent.com/sigstore/root-signing/refs/heads/main/targets/trusted_root.json

# Download CPython artifacts
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

./cosign-linux-amd64 verify-blob \
  --new-bundle-format \
  --certificate-oidc-issuer 'https://accounts.google.com' \
  --certificate-identity 'thomas@python.org' \
  --bundle ./Python-3.13.0.tgz.sigstore \
  # --offline and --trust-root optional for offline verification
  --offline \
  --trust-root ./trusted_root.json \
  ./Python-3.13.0.tgz