Skip to content

Commit 3e2f25f

Browse files
sethmlarsonhugovkJelleZijlstra
authored
PEP 761: Deprecating PGP signatures for CPython artifacts (#4027)
Co-authored-by: Hugo van Kemenade <[email protected]> Co-authored-by: Jelle Zijlstra <[email protected]>
1 parent 0dc7d13 commit 3e2f25f

File tree

2 files changed

+218
-0
lines changed

2 files changed

+218
-0
lines changed

‎.github/CODEOWNERS

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -637,6 +637,7 @@ peps/pep-0756.rst @vstinner
637637
peps/pep-0757.rst @vstinner
638638
peps/pep-0758.rst @pablogsal @brettcannon
639639
peps/pep-0759.rst @warsaw
640+
peps/pep-0761.rst @sethmlarson @hugovk
640641
# ...
641642
peps/pep-0789.rst @njsmith
642643
# ...

‎peps/pep-0761.rst

Lines changed: 217 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,217 @@
1+
PEP: 761
2+
Title: Deprecating PGP signatures for CPython artifacts
3+
Author: Seth Michael Larson <[email protected]>
4+
Sponsor: Hugo van Kemenade
5+
Status: Draft
6+
Type: Process
7+
Created: 08-Oct-2024
8+
Python-Version: 3.14
9+
Post-History: `25-Sep-2024 <https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058>`__
10+
11+
Abstract
12+
========
13+
14+
Since Python 3.11.0, CPython has provided two verifiable digital signatures
15+
for all CPython artifacts: PGP and Sigstore.
16+
17+
PGP's design requires the maintenance and protection of `long-lived private
18+
keys <https://words.filippo.io/giving-up-on-long-term-pgp/>`_ by trusted
19+
parties. PGP's `security and ergonomics have been criticized by security
20+
practitioners <https://www.latacora.com/blog/2019/07/16/the-pgp-problem/>`_
21+
for many years now, with the biggest issue being that there were few
22+
alternatives for "artifact signing" being proposed or adopted.
23+
24+
Sigstore's design philosophy has focused on the ergonomics of signing and
25+
verifying and uses short-lived keys with strongly-bound human-readable
26+
identities via OpenID Connect. Sigstore has both development and adoption
27+
momentum, seeing adoption by PyPI, NPM, Homebrew, and GitHub, among other
28+
ecosystems.
29+
30+
This PEP proposes to move CPython to using Sigstore exclusively for signing
31+
artifacts through a deprecation and eventual discontinuance of providing PGP
32+
signatures with new release managers.
33+
34+
Motivation
35+
==========
36+
37+
CPython's releases are release-manager-centric, where a single person
38+
maintains multiple CPython releases from pre-release to end-of-life over the
39+
course of many years.
40+
41+
Requiring release managers to maintain and protect PGP private keys for seven
42+
or more years is an unnecessary burden in the new age of ergonomic and
43+
ephemeral signing keys. Comparatively, Sigstore only requires release managers
44+
to click a button during the release process to OAuth sign-on to their
45+
identity provider. Maintaining the integrity of accounts on identity providers
46+
like GitHub is already an expectation of being a Python release manager or
47+
core team member, such as through multi-factor authentication and strong
48+
unique passwords.
49+
50+
Rationale
51+
=========
52+
53+
Preserve expectations across a Python release
54+
---------------------------------------------
55+
56+
To avoid breaking downstream verifiers, the expectations for verification
57+
materials availability SHOULD NOT be changed during a feature release's
58+
lifecycle.
59+
60+
Release managers, not releases
61+
------------------------------
62+
63+
The discontinuation of PGP signatures doesn't necessarily have to happen
64+
on a "release manager boundary"; a new Python release could be a potential
65+
boundary.
66+
67+
Because the primary motivation for deprecating PGP is ergonomics, deciding
68+
to drop PGP for one release while a release manager still has obligations to
69+
provide PGP signatures for other releases for multiple years isn't much
70+
savings of effort.
71+
72+
A new release manager also represents a new PGP public key that downstream
73+
verifiers need to adopt. By choosing to make the change during this period,
74+
this minimizes the breakage to a place in downstream maintenance where a
75+
change will already be necessary.
76+
77+
Gordian knot of signing methods and verifiers
78+
---------------------------------------------
79+
80+
CPython providing both PGP and Sigstore signatures concurrently creates a
81+
"`Gordian knot <https://en.wikipedia.org/wiki/Gordian_Knot>`_" where
82+
verifiers are disincentivized to migrate to a new signature method due to the
83+
*continued and expected availability* of an existing signature method, thus
84+
propagating the *apparent demand* for maintaining the existing signature
85+
method.
86+
87+
This situation slows down the adoption of new signature methods like Sigstore for
88+
both signature-producing projects and signature-verifying ecosystems by not
89+
creating a "need" to automate and integrate the signature method into verifier
90+
tooling.
91+
92+
By changing the expectation of what future signature methods will be
93+
available, the incentive-knot can be broken by `spurring the adoption of the
94+
new signature method in downstream tooling <https://lists.debian.org/debian-devel/2024/10/msg00025.html>`_.
95+
This change to verifier tooling also makes other upstream projects able to
96+
migrate to publishing only Sigstore signatures, resulting in a positive
97+
feedback loop of adoption.
98+
99+
Specification
100+
=============
101+
102+
Because PGP keys are tied to a release manager identity, the change to
103+
availability of PGP signatures will be tied to release managers instead of
104+
individual releases (3.13, 3.14, etc). This PEP both deprecates and proposes
105+
a discontinuation timeline for PGP signatures.
106+
107+
Deprecation and discontinuation of PGP signatures
108+
-------------------------------------------------
109+
110+
This PEP deprecates PGP signatures for future CPython releases and recommends
111+
verifiers to adopt Sigstore to verify CPython artifacts as an alternative to
112+
PGP.
113+
114+
This PEP also removes the expectation that PGP signatures be published by
115+
future release managers that don't already maintain a stable Python release.
116+
At the time of writing this would be Hugo van Kemenade, as 3.14 is the next
117+
Python version without a stable release.
118+
119+
Releases which already have a stable release (3.13, 3.12, 3.11, etc) are not
120+
affected and will continue to provide PGP signatures for artifacts until they
121+
are end-of-life. All existing PGP signatures will continue to work as
122+
expected.
123+
124+
Delaying discontinuation of PGP signatures
125+
------------------------------------------
126+
127+
This PEP provides a mechanism to delay the *discontinuation* of PGP signatures
128+
from active and upcoming CPython releases in case of extraordinary
129+
circumstances. *Deprecation* of PGP signatures can't be changed without a
130+
superseding PEP.
131+
132+
The Steering Council MAY at a future date after this PEP's acceptance decide
133+
to delay the discontinuation of PGP signatures to a future CPython release.
134+
If the Steering Council decides to delay the discontinuation of PGP signatures
135+
then all active release managers MUST provide PGP signatures for their covered
136+
CPython artifacts for the remainder of their tenure as a release manager. This
137+
includes all steps required to do so, such as generating a new PGP key and
138+
publishing their identity to python.org.
139+
140+
The discontinuation of PGP signatures then is automatically scheduled for the
141+
next release manager without a stable release, to be highlighted in the
142+
Steering Council decision.
143+
144+
Backwards Compatibility
145+
=======================
146+
147+
This proposal would remove the ability to verify future CPython artifacts
148+
using PGP. Any downstream verifiers using PGP for CPython artifacts would
149+
need to either start using Sigstore, verify their source code of CPython
150+
through other means, or stop verification altogether for future CPython
151+
releases.
152+
153+
Security Implications
154+
=====================
155+
156+
PGP and Sigstore have different security models, so by removing PGP
157+
signatures this means that all users only have the option to rely on the
158+
security model provided by Sigstore.
159+
160+
In general, the security model required for artifact signatures is being
161+
able to detect whether a given artifact is from the expected source and
162+
hasn't been modified, regardless of the security or integrity of the hosting
163+
service (in CPython's case: python.org/downloads).
164+
165+
`Sigstore's security model <https://docs.sigstore.dev/about/security/>`_
166+
depends more on centralized infrastructure compared to PGP, such as the
167+
"public good" signature transparency log (Rekor), certificate authority and
168+
transparency log (Fulcio), and the security of OpenID Connect identity
169+
providers like Google and GitHub.
170+
171+
CPython's development already depends on the security of some of these
172+
services and the others are better resourced than any individual release
173+
manager to provide long-term public key management.
174+
175+
How to Teach This
176+
=================
177+
178+
CPython `already documents <https://www.python.org/downloads/metadata/sigstore/>`_
179+
how to verify artifacts using Sigstore based on the pre-published identities
180+
of release managers. Documentation will be updated to indicate the deprecation
181+
and future expectations of PGP signatures.
182+
183+
Verifying signatures of CPython artifacts isn't something we should expect
184+
from new Python users. Instead, Sigstore is more likely to be a part of a
185+
downstream integrator's build pipeline such as a Linux distro, Homebrew, pyenv,
186+
or others that programmatically fetch and build CPython from source.
187+
188+
Rejected Ideas
189+
==============
190+
191+
Continue publishing PGP signatures indefinitely
192+
-----------------------------------------------
193+
194+
Being a release manager is already a difficult, time-consuming, and long-term
195+
commitment that is typically done on a volunteer basis. Thus we see removal
196+
of PGP key management duties as a step towards reducing burnout and stress
197+
of future release managers and improving the sustainability of CPython.
198+
199+
Appendix
200+
========
201+
202+
Support for offline verification
203+
--------------------------------
204+
205+
During the `pre-PEP discussion <https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058>`_,
206+
there was a question of whether offline verification was supported by
207+
Sigstore. Using a Sigstore bundle (:file:`.sigstore`) file, `Sigstore clients
208+
support verifying the artifact completely offline <https://discuss.python.org/t/pre-pep-discussion-stop-providing-gpg-signatures-for-cpython-artifacts/65058/9>`_.
209+
When in offline mode, Sigstore can't verify whether a signature has been
210+
revoked. This is a similar restriction to PGP key revocations not being
211+
detectable during offline verification.
212+
213+
Copyright
214+
=========
215+
216+
This document is placed in the public domain or under the
217+
CC0-1.0-Universal license, whichever is more permissive.

0 commit comments

Comments
 (0)