PyPI lehnt neue Datei-Uploads 14 Tage nach einer Veröffentlichung ab

PyPI blockiert das Hochladen neuer Dateien zu Veröffentlichungen, die seit 14 Tagen veröffentlicht sind, damit stabile bestehende Releases auch dann nicht nachträglich kompromittiert werden, wenn Token oder Deployment-Workflows übernommen werden
Bislang wurden keine tatsächlichen Missbrauchsfälle bestätigt, aber außer der Tatsache, dass Angreifer diese Möglichkeit offenbar nicht kannten, gab es keine technische Hürde, die einen solchen Angriff verhindert hätte
Eine Untersuchung der 15.000 größten Pakete ergab, dass nur 56 Projekte nach 14 Tagen noch cp314-Wheels für Python 3.14 hinzugefügt hatten
Projekte, die bestehenden Releases bisher nachträglich Unterstützung für neue Python-Versionen hinzugefügt haben, müssen nun die nächste Version veröffentlichen; auch auf dem PyCon US 2026 Packaging Summit wurde dies als akzeptabler Ansatz bewertet
Da es noch keine API gibt, um den offenen oder geschlossenen Status eines Releases zu definieren oder abzufragen, sollte man sich nicht auf dieses Verhalten verlassen; künftig sollen PEP 694 mit der Upload-2.0-API und Staged Previews die zugehörige Semantik festlegen

Warum alte Releases geschlossen werden

Die Änderung in PyPI blockiert den Weg, neue Dateien in alte und stabile Releases hochzuladen
- Dadurch soll verhindert werden, dass bei einer Kompromittierung von Publishing-Token oder Workflows nur Teile eines bestehenden Releases durch bösartige Dateien ersetzt werden
- Ebenso wird ein unklarer Zustand vermieden, in dem kompromittierte und nicht kompromittierte Dateien innerhalb eines Releases gemischt sind, und der Aufräumaufwand für die PyPI-Administration sinkt
Die Diskussion begann im Januar 2024 während der Arbeiten an PEP 740 Digital Attestations und wurde im März 2026 wieder aufgenommen
- Auslöser war die Supply-Chain-Kompromittierung von LiteLLM und Telnyx, deren Ursache eine mutable reference in der von beiden Projekten verwendeten Trivy GitHub Action war
Erste Diskussionen wurden ausgesetzt, weil einige Projekte bereits veröffentlichte Releases um Dateien für neue Python-Versionen ergänzten
- Um die Auswirkungen der Änderung zu erfassen, wurde in der PyPI-Datenbank untersucht, welche Projekte Dateien zu alten Releases hinzugefügt hatten, aufgeschlüsselt nach vergangenen Tagen
- Eine gesonderte Prüfung der cp314-Wheels der 15.000 größten Pakete ergab, dass 56 Projekte nach 14 Tagen noch Python-3.14-kompatible Wheels veröffentlicht hatten

Auf dem PyCon US 2026 Packaging Summit entstand ein grober Konsens, dass es akzeptabel ist, für die Unterstützung neuer Python-Versionen eine neue Folgeverson zu verlangen
Auf Basis der erhobenen Daten und dieses Konsenses wurde der Warehouse-Patch vorangetrieben und am 8. Juli 2026 zusammengeführt
Die aktuelle Einschränkung kann noch nicht als stabile Schnittstelle betrachtet werden
- Die Definition eines Releases, das „keine neuen Dateien mehr annimmt“, ist noch nicht abgeschlossen, und es gibt auch keine API, um diesen Status abzufragen
- Erst nachdem PEP 694 die Upload-2.0-API und Staged Previews standardisiert hat, soll eine Semantik entstehen, in der Releases als open oder closed behandelt werden