Erwartungen über eine Python-Version hinweg beibehalten

Um nachgelagerte Verifizierer nicht zu beeinträchtigen, dürfen die Erwartungen an die Verfügbarkeit von Verifizierungsmaterialien während des Lebenszyklus einer Feature-Version **nicht** geändert werden.

Release Manager, nicht Releases

Die Einstellung von PGP-Signaturen muss nicht unbedingt an einer „Release-Manager-Grenze“ erfolgen; eine neue Python-Version könnte eine potenzielle Grenze darstellen.

Da die Hauptmotivation für die Deprecation von PGP die Ergonomie ist, ist die Entscheidung, PGP für eine Version fallen zu lassen, während ein Release Manager noch Verpflichtungen zur Bereitstellung von PGP-Signaturen für andere Releases über viele Jahre hinweg hat, keine große Arbeitsersparnis.

Ein neuer Release Manager repräsentiert auch einen neuen PGP-Public-Schlüssel, den nachgelagerte Verifizierer übernehmen müssen. Durch die Wahl, die Änderung während dieser Zeit vorzunehmen, wird die Unterbrechung auf einen Punkt in der nachgelagerten Wartung minimiert, an dem eine Änderung ohnehin notwendig sein wird.

Gordischer Knoten von Signaturmethoden und Verifizierern

CPython, das gleichzeitig PGP- und Sigstore-Signaturen bereitstellt, schafft einen „Gordischen Knoten“, bei dem Verifizierer demotiviert sind, zu einer neuen Signaturmethode zu migrieren, da eine bestehende Signaturmethode ständig und erwartungsgemäß verfügbar ist, wodurch die scheinbare Nachfrage nach der Beibehaltung der bestehenden Signaturmethode aufrechterhalten wird.

Diese Situation verlangsamt die Übernahme neuer Signaturmethoden wie Sigstore sowohl für signaturproduzierende Projekte als auch für signaturverifizierende Ökosysteme, da kein „Bedarf“ geschaffen wird, die Signaturmethode in der Verifizierungswerkzeugkette zu automatisieren und zu integrieren.

Durch die Änderung der Erwartung, welche zukünftigen Signaturmethoden verfügbar sein werden, kann der Anreizknoten durch Anschub der Übernahme der neuen Signaturmethode in nachgelagerten Werkzeugen durchbrochen werden. Diese Änderung an der Verifizierungswerkzeugkette ermöglicht es auch anderen vorgelagerten Projekten, nur noch Sigstore-Signaturen zu veröffentlichen, was zu einer positiven Rückkopplungsschleife der Übernahme führt.

Deprecation und Einstellung von PGP-Signaturen

Diese PEP deklariert PGP-Signaturen für zukünftige CPython-Releases als veraltet und empfiehlt Verifizierern, Sigstore zur Verifizierung von CPython-Artefakten als Alternative zu PGP zu verwenden.

Diese PEP enthebt auch zukünftige Release Manager, die keine stabile Python-Version mehr betreuen, der Erwartung, PGP-Signaturen zu veröffentlichen. Zum Zeitpunkt der Erstellung dieser PEP wäre dies Hugo van Kemenade, da 3.14 die nächste Python-Version ohne stabile Veröffentlichung ist.

Releases, die bereits eine stabile Version haben (3.13, 3.12, 3.11 usw.), sind nicht betroffen und werden weiterhin PGP-Signaturen für Artefakte bereitstellen, bis sie ihr Lebensende erreicht haben. Alle vorhandenen PGP-Signaturen funktionieren weiterhin wie erwartet.

Verzögerung der Einstellung von PGP-Signaturen

Diese PEP bietet einen Mechanismus zur Verzögerung der Einstellung von PGP-Signaturen von aktiven und anstehenden CPython-Releases im Falle außergewöhnlicher Umstände. Die Deprecation von PGP-Signaturen kann nicht ohne eine nachfolgende PEP geändert werden.

Der Steering Council KANN zu einem späteren Zeitpunkt nach der Annahme dieser PEP entscheiden, die Einstellung von PGP-Signaturen auf eine zukünftige CPython-Version zu verschieben. Wenn der Steering Council beschließt, die Einstellung von PGP-Signaturen zu verschieben, MÜSSEN alle aktiven Release Manager PGP-Signaturen für ihre betroffenen CPython-Artefakte für den Rest ihrer Amtszeit als Release Manager bereitstellen. Dies beinhaltet alle dazu erforderlichen Schritte, wie z. B. die Erstellung eines neuen PGP-Schlüssels und die Veröffentlichung ihrer Identität auf python.org.

Die Einstellung von PGP-Signaturen wird dann automatisch für den nächsten Release Manager ohne stabile Veröffentlichung geplant und in der Entscheidung des Steering Council hervorgehoben.

PGP-Signaturen weiterhin unbegrenzt veröffentlichen

Ein Release Manager zu sein ist bereits eine schwierige, zeitaufwändige und langfristige Verpflichtung, die normalerweise ehrenamtlich geleistet wird. Daher sehen wir die Entfernung von PGP-Schlüsselverwaltungsaufgaben als einen Schritt zur Reduzierung von Burnout und Stress für zukünftige Release Manager und zur Verbesserung der Nachhaltigkeit von CPython.

Entfernen früherer PGP-Signaturen

Diese PEP zielt nicht darauf ab, bestehende Infrastruktur, die auf vorhandenen Python-Versionen basiert, zu beeinträchtigen, sondern ändert lediglich die Erwartungen für zukünftige Python-Versionen. Daher werden alle PGP-Signaturen, die bereits auf python.org verfügbar sind, auch nach der Einstellung von PGP weiterhin verfügbar sein.

Unterstützung für Offline-Verifizierung

Während der Vorab-PEP-Diskussion wurde die Frage aufgeworfen, ob die Offline-Verifizierung von Sigstore unterstützt wird. Mithilfe einer Sigstore-Bundle-Datei (.sigstore) unterstützen Sigstore-Clients die vollständige Offline-Verifizierung des Artefakts.

Die Verwendung der Offline-Verifizierung mit Sigstore erfordert die Deaktivierung von Root-of-Trust-Updates und das „Pinnen“ eines Root-of-Trust in einer Datei, die während der Verifizierung verwendet wird.

Das Pinnen eines Root-of-Trust bedeutet, dass Signaturen, die nach der Etablierung eines neuen Root-of-Trust erstellt wurden, mit einem „gepinnten“ früheren Root-of-Trust nicht mehr verifiziert werden können. Neue Root-of-Trusts sind seltene Ereignisse, z. B. wenn der Root-of-Trust kompromittiert wird, und in diesem Fall möchten Verifizierer, dass Signaturen fehlschlagen.

Die Offline-Verifizierung macht auch Widerrufprüfungen unmöglich, aber dies ähnelt dem Modell von PGP, bei dem der Widerruf von Schlüsseln eine Online-Suche erfordert.

Abgesehen von seltenen Ereignissen wie einer Kompromittierung des Root-of-Trust erfordert die Verwendung der Offline-Verifizierung mit Sigstore keine zusätzlichen betrieblichen Anforderungen für Verifizierer.

Unterstützung für eine vorkompilierte ausführbare Datei zur Verifizierung

Während der Diskussion gab es Anfragen nach einer vorkompilierten ausführbaren Datei, die zur Verifizierung von Sigstore-Bundles verwendet werden könnte, ohne dass dafür entweder eine Go-Build-Toolchain installiert werden muss, um sigstore-go aus dem Quellcode zu kompilieren, oder bereits eine funktionierende Python-Installation für sigstore-python vorhanden sein muss.

Cosign ist ein weiteres Sigstore-Projekt, das vorkompilierte eigenständige Binärdateien bereitstellt und die Offline-Verifizierung von Bundles unterstützt.

# 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://#' \
  --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