PyPI rechaza la carga de archivos nuevos 14 días después de una release

PyPI bloquea la carga de archivos nuevos en releases publicadas hace más de 14 días para evitar que una release existente y estable se contamine, incluso si un token o workflow de despliegue es comprometido
Hasta ahora no se han confirmado casos reales de abuso, pero aparte de que los atacantes quizá no conocían esta posibilidad, no existía una barrera técnica que impidiera el ataque
Tras analizar los 15,000 paquetes principales, solo 56 proyectos habían agregado ruedas cp314 para Python 3.14 después de 14 días de la release
Los proyectos que agregaban soporte para nuevas versiones de Python a releases existentes ahora tendrán que publicar una versión siguiente, y en el Packaging Summit de PyCon US 2026 también se consideró una medida aceptable
Aún no existe una API para definir o verificar si una release está abierta o cerrada, por lo que no se debe depender de este comportamiento; en el futuro, PEP 694 y su Upload 2.0 API junto con Staged Previews establecerán esa semántica

Por qué se cierran las releases antiguas

El cambio en PyPI bloquea la vía para subir archivos nuevos a releases antiguas y estables
- Evita situaciones en las que solo una parte de una release existente sea reemplazada por archivos maliciosos, incluso si el token de publicación o el workflow del proyecto son comprometidos
- También evita un estado ambiguo en el que se mezclen archivos comprometidos y no comprometidos dentro de una misma release, además de reducir el trabajo de limpieza para los administradores de PyPI
La discusión comenzó en enero de 2024 durante el trabajo de PEP 740 Digital Attestations, y se retomó en marzo de 2026
- El detonante fue la compromisión de la cadena de suministro de LiteLLM y Telnyx, causada por una referencia mutable en la GitHub Action de Trivy que usaban ambos proyectos
Algunas proyectos ya estaban agregando archivos de soporte para nuevas versiones de Python a releases publicadas, por lo que la discusión inicial se detuvo
- Para medir el impacto del cambio, se investigó en la base de datos de PyPI qué proyectos habían agregado archivos a releases antiguas según los días transcurridos
- Al revisar por separado las ruedas cp314 de los 15,000 paquetes principales, se encontró que 56 proyectos publicaron ruedas compatibles con Python 3.14 después de 14 días

En el Packaging Summit de PyCon US 2026 se formó un consenso general de que es aceptable exigir pasar a la siguiente versión al agregar soporte para una nueva versión de Python
Con base en los datos investigados y ese consenso, avanzó el parche de Warehouse, que fue fusionado el 8 de julio de 2026
La restricción actual todavía no puede considerarse una interfaz estable
- Aún no está definida formalmente qué significa una “release que ya no acepta archivos nuevos”, ni existe una API para consultar ese estado
- Después de que PEP 694 estandarice Upload 2.0 API y Staged Previews, se espera contar con una semántica para tratar las releases como open o closed