PyPI Blog: Releases now reject new files after 14 days
PyPI has implemented a new policy, rejecting new file uploads to releases older than 14 days to enhance supply chain security. This change was spurred by recent package compromises and aims to prevent poisoning of stable releases. Hacker News discusses the implications for package maintainers, the accidental flexibility of previous PyPI behavior, and the broader context of software supply chain integrity.
The Lowdown
The Python Package Index (PyPI) has introduced a significant policy update: new files can no longer be uploaded to existing package releases that are older than 14 days. This proactive measure is a direct response to growing concerns over supply chain security and the potential for malicious actors to compromise older, seemingly stable packages by injecting harmful files.
- The Policy: After a 14-day window following its initial publication, a PyPI release is considered immutable, preventing any further file additions.
- Security Motivation: The primary goal is to safeguard against package poisoning, where an attacker, having gained control of a project's publishing credentials or workflow, could upload malicious files to an old release.
- Incident-Driven Change: The discussion for this policy, initially stalled, gained urgency after high-profile compromises of packages like LiteLLM and Telnyx in April 2026, which exploited "mutable references" in their build processes.
- Minimal Disruption: PyPI data analysis revealed that very few projects (56 out of 15,000 for Python 3.14 wheels) actually relied on the ability to add new files to old releases more than 14 days after publication, indicating low disruption.
- Future Plans: This restriction is an interim step. Upcoming "Upload 2.0 API" and "Staged Previews" (standardized by PEP 694) will introduce more defined semantics for "closed" versus "open" releases.
This change marks a critical step in hardening the Python ecosystem's security posture, protecting users from potential threats, and streamlining incident response by eliminating ambiguous package states. It reinforces the principle that once a package version is released, its composition should be stable and predictable.
The Gossip
Security Scrutiny & Supply Chain Safety
Commenters largely welcome the security improvement but also reflect on the broader challenges of software supply chain security. There's surprise that the ability to add files to old releases was even possible, with some drawing parallels to the importance of hash pinning in other ecosystems. The discussion highlights a general desire for more robust, immutable dependencies across the software world.
The Unexpected Use Cases
The discussion delves into why this behavior existed and what edge cases might be affected. One commenter points out that while the PyPI database analysis showed low disruption for *uploading* new wheels, it doesn't account for complex projects (e.g., those with GPU-specific binaries like CUDA) that might leverage external build processes or workarounds that this policy won't directly address. Another comment from a PyPI staff member clarifies that the "uploading new wheels to an old release" capability was somewhat of an "accident" of the old stateless API design.