PyPI refuse l’ajout de nouveaux fichiers 14 jours après une release

PyPI bloque l’ajout de nouveaux fichiers aux releases publiées depuis plus de 14 jours, afin d’éviter qu’une release existante et stable soit contaminée même si un token ou un workflow de publication est compromis
Aucun cas d’exploitation réelle n’a été confirmé à ce jour, mais il n’existait aucune barrière technique pour empêcher une attaque, hormis le fait que les attaquants n’avaient pas connaissance de cette possibilité
L’examen des 15 000 principaux packages montre que seuls 56 projets avaient ajouté des wheels cp314 pour Python 3.14 plus de 14 jours après une release
Les projets qui ajoutaient la prise en charge d’une nouvelle version de Python à une release existante devront désormais publier une nouvelle version, une approche jugée acceptable lors du Packaging Summit de PyCon US 2026
Il n’existe pas encore d’API pour définir ou vérifier l’état ouvert ou fermé d’une release ; il ne faut donc pas dépendre de ce comportement. À l’avenir, l’API Upload 2.0 et les Staged Previews de PEP 694 devraient en établir la sémantique

Pourquoi fermer les anciennes releases

Le changement apporté à PyPI bloque la possibilité d’ajouter de nouveaux fichiers à des releases anciennes et stables
- Il évite qu’une partie d’une release existante soit remplacée par des fichiers malveillants si le token de publication ou le workflow d’un projet est compromis
- Il empêche qu’une release se retrouve dans un état ambigu, mêlant fichiers compromis et non compromis, et réduit aussi le travail de nettoyage pour les administrateurs de PyPI
La discussion a commencé en janvier 2024, pendant les travaux sur PEP 740 Digital Attestations, puis a repris en mars 2026
- Le déclencheur a été la compromission de la chaîne d’approvisionnement de LiteLLM et Telnyx, causée par une référence modifiable (mutable reference) dans la GitHub Action Trivy utilisée par les deux projets
Les premières discussions ont été interrompues, car certains projets ajoutaient déjà à des releases publiées des fichiers prenant en charge de nouvelles versions de Python
- Pour mesurer l’impact du changement, la base de données de PyPI a été analysée afin d’identifier les projets ayant ajouté des fichiers à d’anciennes releases, selon le nombre de jours écoulés
- Une vérification séparée des wheels cp314 parmi les 15 000 principaux packages a montré que 56 projets avaient publié des wheels compatibles Python 3.14 après 14 jours

Lors du Packaging Summit de PyCon US 2026, un consensus général s’est dégagé : il est acceptable d’exiger le passage à une nouvelle version pour prendre en charge une nouvelle version de Python
Sur la base des données d’analyse et de ce consensus, le patch Warehouse a été proposé, puis fusionné le 8 juillet 2026
La restriction actuelle ne peut pas encore être considérée comme une interface stable
- La définition d’une « release qui n’accepte plus de nouveaux fichiers » n’est pas finalisée, et aucune API ne permet d’en vérifier l’état
- Une fois que PEP 694 aura standardisé l’API Upload 2.0 et les Staged Previews, une sémantique devrait être établie pour traiter les releases comme open ou closed