Since Python 3.11.0, CPython has provided two verifiable digital signaturesfor all CPython artifacts: PGP and Sigstore.
PGP’s design requires the maintenance and protection oflong-lived privatekeys by trustedparties. PGP’ssecurity and ergonomics have been criticized by securitypractitionersfor many years now, with the biggest issue being that there were fewalternatives for “artifact signing” being proposed or adopted.
Sigstore’s design philosophy has focused on theergonomics of signing and verifying anduses short-lived keys withstrongly-bound human-readable identities via OpenID Connect.Sigstore has both development and adoption momentum, seeing adoption by PyPI,NPM, Homebrew, and GitHub, among other ecosystems.
This PEP proposes to move CPython to using Sigstore exclusively for signingartifacts through a deprecation and eventual discontinuance of providing PGPsignatures with new release managers.
CPython’s releases are release-manager-centric, where a single personmaintains multiple CPython releases from pre-release to end-of-life over thecourse of many years.
Requiring release managers to maintain and protect PGP private keys for sevenor more years is an unnecessary burden in the new age of ergonomic andephemeral signing keys. Comparatively, Sigstore only requires release managersto click a button during the release process to OAuth sign-on to theiridentity provider. Maintaining the integrity of accounts on identity providerslike GitHub is already an expectation of being a Python release manager orcore team member, such as through multi-factor authentication and strongunique passwords.
To avoid breaking downstream verifiers, the expectations for verificationmaterials availability SHOULD NOT be changed during a feature release’slifecycle.
The discontinuation of PGP signatures doesn’t necessarily have to happenon a “release manager boundary”; a new Python release could be a potentialboundary.
Because the primary motivation for deprecating PGP is ergonomics, decidingto drop PGP for one release while a release manager still has obligations toprovide PGP signatures for other releases for multiple years isn’t muchsavings of effort.
A new release manager also represents a new PGP public key that downstreamverifiers need to adopt. By choosing to make the change during this period,this minimizes the breakage to a place in downstream maintenance where achange will already be necessary.
CPython providing both PGP and Sigstore signatures concurrently creates a“Gordian knot” whereverifiers are disincentivized to migrate to a new signature method due to thecontinued and expected availability of an existing signature method, thuspropagating theapparent demand for maintaining the existing signaturemethod.
This situation slows down the adoption of new signature methods like Sigstore forboth signature-producing projects and signature-verifying ecosystems by notcreating a “need” to automate and integrate the signature method into verifiertooling.
By changing the expectation of what future signature methods will beavailable, the incentive-knot can be broken byspurring the adoption of thenew signature method in downstream tooling.This change to verifier tooling also makes other upstream projects able tomigrate to publishing only Sigstore signatures, resulting in a positivefeedback loop of adoption.
Because PGP keys are tied to a release manager identity, the change toavailability of PGP signatures will be tied to release managers instead ofindividual releases (3.13, 3.14, etc). This PEP both deprecates and proposesa discontinuation timeline for PGP signatures.
This PEP deprecates PGP signatures for future CPython releases and recommendsverifiers to adopt Sigstore to verify CPython artifacts as an alternative toPGP.
This PEP also removes the expectation that PGP signatures be published byfuture 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 nextPython version without a stable release.
Releases which already have a stable release (3.13, 3.12, 3.11, etc) are notaffected and will continue to provide PGP signatures for artifacts until theyare end-of-life. All existing PGP signatures will continue to work asexpected.
This PEP provides a mechanism to delay thediscontinuation of PGP signaturesfrom active and upcoming CPython releases in case of extraordinarycircumstances.Deprecation of PGP signatures can’t be changed without asuperseding PEP.
The Steering Council MAY at a future date after this PEP’s acceptance decideto delay the discontinuation of PGP signatures to a future CPython release.If the Steering Council decides to delay the discontinuation of PGP signaturesthen all active release managers MUST provide PGP signatures for their coveredCPython artifacts for the remainder of their tenure as a release manager. Thisincludes all steps required to do so, such as generating a new PGP key andpublishing their identity to python.org.
The discontinuation of PGP signatures then is automatically scheduled for thenext release manager without a stable release, to be highlighted in theSteering Council decision.
This proposal would remove the ability to verify future CPython artifactsusing PGP. Any downstream verifiers using PGP for CPython artifacts wouldneed to either start using Sigstore, verify their source code of CPythonthrough other means, or stop verification altogether for future CPythonreleases.
PGP and Sigstore have different security models, so by removing PGPsignatures this means that all users only have the option to rely on thesecurity model provided by Sigstore.
In general, the security model required for artifact signatures is beingable to detect whether a given artifact is from the expected source andhasn’t been modified, regardless of the security or integrity of the hostingservice (in CPython’s case: python.org/downloads).
Sigstore’s security modeldepends more on centralized infrastructure compared to PGP, such as the“public good” signature transparency log (Rekor), certificate authority andtransparency log (Fulcio), and the security of OpenID Connect identityproviders like Google and GitHub.
CPython’s development already depends on the security of some of theseservices and the others are better resourced than any individual releasemanager to provide long-term public key management.
CPythonalready documentshow to verify artifacts using Sigstore based on the pre-published identitiesof release managers. Documentation will be updated to indicate the deprecationand future expectations of PGP signatures.
Verifying signatures of CPython artifacts isn’t something we should expectfrom new Python users. Instead, Sigstore is more likely to be a part of adownstream integrator’s build pipeline such as a Linux distro, Homebrew, pyenv,or others that programmatically fetch and build CPython from source.
Being a release manager is already a difficult, time-consuming, and long-termcommitment that is typically done on a volunteer basis. Thus we see removalof PGP key management duties as a step towards reducing burnout and stressof future release managers and improving the sustainability of CPython.
This PEP doesn’t intend to break any infrastructure built around existing Pythonversions, instead only changing the expectations around future Python versions.Thus all PGP signatures that are already available on python.org will continueto be available even after PGP discontinuance.
During thepre-PEP discussion,there was a question of whether offline verification was supported bySigstore. Using a Sigstore bundle (.sigstore) file,Sigstore clientssupport verifying the artifact completely offline.
Using offline verification with Sigstore requires disabling root of trustupdates and “pinning” a root of trust in a file to use during verification.
Pinning a root of trust means signatures made after anew root of trustis established would no longer be able to verify using a “pinned” previousroot of trust. New roots of trust are expected to be rare events, such aswhen the root of trust is compromised, and in this case verifiers wouldwant signatures to fail to verify.
Offline verification also makes revocation checks impossible, but thisis similar to PGP’s model where revocation of keys requires an online lookup.
Barring rare events like root of trust compromise, using offline verificationwith Sigstore doesn’t impose additional operations requirements to verifiers.
During discussion there were requests for a pre-compiled executable that couldbe used for verifying Sigstore bundles without needing to either installa Go build toolchain to buildsigstore-gofrom source or already have a working Python installation forsigstore-python.
Cosign is another Sigstore projectthat provides pre-compiled standalone binaries and supports verifying bundlesoffline:
# Download Cosignwgethttps://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.jsonwgethttps://raw.githubusercontent.com/sigstore/root-signing/refs/heads/main/targets/trusted_root.json# Download CPython artifactswgethttps://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgzwgethttps://www.python.org/ftp/python/3.13.0/Python-3.13.0.tgz.sigstore./cosign-linux-amd64verify-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
This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.
Source:https://github.com/python/peps/blob/main/peps/pep-0761.rst
Last modified:2024-11-06 19:20:02 GMT