导航|地址|刷新
The Python Package Index Blog

?xml version="1.0" encoding="UTF-8" ?> The Python Package Index BlogThe official blog of the Python Package Indexhttps://blog.pypi.org/https://github.com/pypi/warehouseenFri, 31 Jul 2026 23:53:29 -0000Fri, 31 Jul 2026 23:53:29 -00001440MkDocs RSS plugin - v1.17.9https://blog.pypi.org/assets/logo.pngThe Python Package Index Bloghttps://blog.pypi.org/Releases now reject new files after 14 daysSeth Larsonsecurity<p>The Python Package Index (PyPI) now rejects new files being uploaded to releases that are older than 14 days. This restriction was <a href="https://github.com/pypi/warehouse/pull/19727">put in place</a> to prevent old and long-stable releases from being poisoned in case publishing tokens or workflows of PyPI projects were compromised. As far as we are aware this has not yet been abused, but there is no technical reason beyond that attackers weren't aware it was possible.</p>  <p>Users should not yet rely on this behavior as there are no defined semantics for "releases no longer accepting new files" or APIs available to confirm the state of the release. Instead, these semantics will be defined once "Upload 2.0 API" and "Staged Previews" have been standardized by <a href="https://peps.python.org/pep-0694/">PEP 694</a>.</p> <p>The <a href="https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566">discussion of this behavior began</a> during PEP 740 (Digital Attestations) back in January 2024. The discussion was <a href="https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/34">restarted in March 2026</a> after the popular packages <a href="https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/">LiteLLM and Telnyx were compromised</a>. These packages were compromised due to a "<a href="https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/">mutable reference</a>" in these projects' usage of the Trivy GitHub Action.</p> <p>Originally the discussion stalled due to some projects depending on this behavior to add support for new Python versions to already-published releases. To quantify how disruptive this change would be to existing workflows, the PyPI database was queried for <a href="https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/48">projects that have published new files to old releases</a> (bucketed by number of days since the release). Later, specifically <code>cp314</code> wheels were queried for the top 15,000 packages, revealing that <a href="https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/63">only 56 projects of 15,000</a> had published a 3.14-compatible wheel more than 14 days after a release was available.</p> <p>This topic was brought to the <a href="https://hackmd.io/k0C-RAIVRnu-YXoDFgABvA">Packaging Summit at PyCon US 2026</a> by PyPI Safety & Security Engineer, Mike Fiedler. The rough consensus of the discussion was that the summit attendees thought it was "acceptable to require users to bump to the next version" to support new Python versions. With the data and consensus in hand, Seth <a href="https://github.com/pypi/warehouse/pull/19727">moved forward with a patch</a> to reject new files on old releases which was merged July 8th, 2026.</p> <p>This change will protect Python users and reduce the amount of "cleanup" work associated with project compromises for PyPI admins. This restriction also means that compromises don't put releases into an indeterminate and confusing state of both "compromised" and "not compromised", where only a subset of files could be poisoned with malware. Stay tuned for the future where Upload 2.0 API provides semantics for releases that are "closed" instead of "open".</p> <p>Seth Larson and Mike Fiedler's work at the Python Software Foundation is supported by <a href="https://alpha-omega.dev/">Alpha-Omega</a>.</p>https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/Wed, 22 Jul 2026 12:00:00 +0000The Python Package Index Bloghttps://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/Planned Updates to the PyPI User InterfaceNicole Harrissecurityuser-interface<p>Over the next few months, we will be rolling out changes to the PyPI user interface, improving how we surface security signals and updating the pages where users view package details.</p> <p>Updates will be staged to <a href="https://test.pypi.org/">TestPyPI</a> and deployed to production in phases. This approach allows our team to thoroughly test the UI with production-like data, while providing the community with an opportunity to share feedback.</p> <p>The first phase of changes is now staged on <a href="https://test.pypi.org/">TestPyPI</a> and ready for users to review!</p>  <h2 id="context-ui-history-user-research-and-attestations-style-guide">Context: UI History, User Research and Attestations Style Guide</h2> <p>The PyPI user interface has remained largely unchanged since its 2018 launch. Over the intervening years, both PyPI and the Python ecosystem have grown significantly, while also attracting a higher volume of malicious activity. As a result, PyPI is taking a more active role in helping users assess and understand package security.</p> <p>In 2024, PyPI <a href="../2024-11-14-pypi-now-supports-digital-attestations/">introduced support for digital attestations</a>. Uploaded by project maintainers when making a new release, attestations serve as a signed record of a release's build or publishing <em>provenance</em>, providing a verifiable way for users to see exactly where the release files came from.</p> <p>While this was a significant milestone, the initial release did not include the necessary UI updates to make those attestations easily understandable or consumable for the average PyPI user.</p> <p>This isn't a PyPI-specific problem; communicating attestations clearly to end users is a challenge across the open source ecosystem. To address this, the <a href="https://repos.openssf.org/">OpenSSF Securing Software Repositories Working Group</a> partnered with <a href="https://superbloom.design/">Superbloom</a> and <a href="https://kabucreative.com/">Kabu Creative</a> in 2025 to research and develop a standardized <a href="https://repos.openssf.org/attestations-style-guide">style guide for displaying attestations on software repositories</a>. This work included extensive user interviews with package consumers (including PyPI users) to understand how they evaluate package security and trustworthiness.</p> <p>As a next step, PyPI is adopting the <a href="https://repos.openssf.org/attestations-style-guide/level-aaa">highest-level recommendations</a> from the style guide, becoming the first package repository to do so. Most notably, this involves adding a new "Security" tab and improving PyPI's user documentation.</p> <p>We are also using this opportunity to deliver incremental improvements to the project detail pages, fine-tuning our 2018 design to improve information hierarchy and utility.</p> <h2 id="whats-changing">What's Changing?</h2> <p>Key changes to the user interface include:</p> <ul> <li> <p><strong>Dedicated Security Tab:</strong> We are introducing a new Security tab to the project page to centralize provenance and attestation metadata, and to provide clear indicators when provenance is missing or has changed.</p> </li> <li> <p><strong>Navigation Moved to Horizontal Tabs:</strong> We are moving internal navigation out of the sidebar and into a horizontal tab structure. This allows us to reserve the sidebar exclusively for project- and release-related metadata.</p> </li> <li> <p><strong>Metadata Sidebar Moved to the Right:</strong> We are shifting the sidebar to the right to place critical content (the package description/readme) on the left, aligning with a natural left-to-right reading pattern and mirroring the structure of other major platforms like GitHub and npm.</p> </li> <li> <p><strong>Labeling Trust Levels:</strong> We are explicitly labeling project data intrinsic to PyPI (like release timestamps) and data provided by a maintainer and verified by PyPI (like upstream source repositories). This will help users weigh the trustworthiness of data according to its source.</p> </li> <li> <p><strong>Optimized Sidebar Hierarchy:</strong> We are reordering sidebar metadata by utility, prioritizing project links and "freshness" signals (like release dates) at the top, while shifting classification data to the bottom.</p> </li> <li> <p><strong>Clearer Status Labeling:</strong> We are introducing bolder colors and improved labels for quarantined, yanked, archived, and pre-release states to help users more easily distinguish between these conditions.</p> </li> </ul> <p>These updates are entirely visual and will not require action from project maintainers; existing and future digital attestations will map to the new UI automatically.</p> <h2 id="our-rollout-plan">Our Rollout Plan</h2> <p>We are rolling out these changes in four phases. You can follow our progress, view the design prototypes, and participate in the discussion on our <a href="https://github.com/pypi/warehouse/issues/19950">main tracking issue (#19950)</a>.</p> <ul> <li><strong>Phase 1: Project Details</strong> (prototypes and discussion at <a href="https://github.com/pypi/warehouse/issues/19951">#19951</a>, now live on <a href="https://test.pypi.org/">TestPyPI</a>) – Main page redesign, including updates to the sidebar order and positioning.</li> <li><strong>Phase 2: Files and Release History</strong> (prototypes and discussion at <a href="https://github.com/pypi/warehouse/issues/20185">#20185</a>) – Streamlining the file and release history tabs, adding attestation metadata where appropriate.</li> <li><strong>Phase 3: Security Tab</strong> (prototypes and discussion at <a href="https://github.com/pypi/warehouse/issues/20069">#20069</a>) – Building a dedicated space for surfacing provenance and attestation data, raising warnings where appropriate.</li> <li><strong>Phase 4: Documentation Refresh</strong> – Refreshing PyPI's documentation to support the new UI, including adding security guidance.</li> </ul> <h2 id="we-want-your-feedback">We Want Your Feedback</h2> <p>We invite you to test these changes on <a href="https://test.pypi.org/">TestPyPI</a>.</p> <p>If you have feedback, please share it on <a href="https://github.com/pypi/warehouse/issues/20267">this GitHub issue</a>.</p> <p>If you find a bug or defect, please open a ticket on <a href="https://github.com/pypi/warehouse/issues">our issue tracker</a>. Please ensure you include browser and device details. This helps our team reproduce and fix the problem quickly.</p> <h2 id="acknowledgments">Acknowledgments</h2> <p>We would like to thank the <a href="https://openssf.org/">Open Source Security Foundation</a> for providing the funding for this initiative. We are also deeply grateful to Dustin Ingram, Zach Steindler, and the members of the <a href="https://repos.openssf.org/">OpenSSF Securing Software Repos WG</a> for proposing this project for funding, and championing the larger effort to introduce attestations.</p> <p>We also want to extend a sincere thank you to the members of the Python community who participated in our most recent round of <a href="https://github.com/pypi/warehouse/issues/20111">user interviews</a>; your insights were instrumental in shaping the rationale and execution of these designs. Volunteers included:</p> <ul> <li>Maciej Kopeć</li> <li>Yngve Moe</li> <li>Nyaosi Mogaka</li> <li>Joachim Jablon</li> <li>Samuel Mbote</li> </ul> <p>Finally, thank you to the 777 people who participated in our recent <a href="https://github.com/pypi/warehouse/issues/20058">user survey</a>. Your feedback has been invaluable in shaping the design and ordering of the package metadata sidebar.</p>https://blog.pypi.org/posts/2026-07-22-ui-updates/Wed, 22 Jul 2026 06:09:00 +0000The Python Package Index Bloghttps://blog.pypi.org/posts/2026-07-22-ui-updates/PyPI has completed its second auditMike Fiedlersecuritytransparency<p>In 2023 <a href="../2023-11-14-1-pypi-completes-first-security-audit/">PyPI completed its first security audit</a>, and I am proud to announce that we have now completed our second external security audit.</p> <p>This work was funded by the <a href="https://www.sovereign.tech/">Sovereign Tech Agency</a>, a supporter of Open Source security-related improvements, partnering with <a href="https://www.trailofbits.com/">Trail of Bits</a> to perform the audit. Thanks to ongoing support from <a href="https://alpha-omega.dev/">Alpha-Omega</a>, my role at the PSF enabled me to focus on rapid remediation of the findings.</p> <p>This time around, there's no three-part series, as the scope was narrower, focused only on PyPI's codebase and behaviors. Read on for a summary of issues identified, their resolutions, and more details about the audit process.</p>  <p>The full audit report can be found on the <a href="https://github.com/trailofbits/publications/blob/master/reviews/2026-04-pypi-warehouse-securityreview.pdf">Trail of Bits publication page</a>. I highly recommend reading that for the fullest context first.</p> <h2 id="findings">Findings</h2> <p>Here's a table of the findings, status, and links to the relevant pull requests where applicable:</p> <table> <thead> <tr> <th style="text-align: left;">ID</th> <th style="text-align: left;">Title</th> <th style="text-align: left;">Severity</th> <th style="text-align: left;">Difficulty</th> <th style="text-align: left;">Status</th> </tr> </thead> <tbody> <tr> <td style="text-align: left;"><a href="#tob-pypi26-1-oidc-jti-anti-replay-lock-expires-before-jwt-leeway-window-closes">TOB-PYPI26-1</a></td> <td style="text-align: left;">OIDC JTI anti-replay lock expires before JWT leeway window closes</td> <td style="text-align: left;">Medium</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19627">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-2</td> <td style="text-align: left;">OIDC token minting is vulnerable to a TOCTOU race in JTI anti-replay</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19625">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-3</td> <td style="text-align: left;">Verification badge bypass on the home page and download URLs</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">Low</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19628">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-4</td> <td style="text-align: left;">Project-level token deletion audit events silently dropped due to data structure mismatch</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">Low</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19652">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-5</td> <td style="text-align: left;">Password reset leaks privileged account status</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19653">Remediated</a></td> </tr> <tr> <td style="text-align: left;"><a href="#tob-pypi26-6-ip-ban-bypass-via-macaroon-api-token-authentication">TOB-PYPI26-6</a></td> <td style="text-align: left;">IP ban bypass via macaroon API token authentication</td> <td style="text-align: left;">Informational</td> <td style="text-align: left;">High</td> <td style="text-align: left;">Accepted</td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-7</td> <td style="text-align: left;">Moderators can modify organization applications due to a missing write permission check</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19619">Remediated</a></td> </tr> <tr> <td style="text-align: left;"><a href="#tob-pypi26-8-organization-members-can-invite-new-owners-due-to-a-missing-manage-permission-check">TOB-PYPI26-8</a></td> <td style="text-align: left;">Organization members can invite new owners due to a missing manage permission check</td> <td style="text-align: left;">High</td> <td style="text-align: left;">Medium</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19610">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-9</td> <td style="text-align: left;">TOTP replay prevention bypass via space normalization mismatch between validation and storage</td> <td style="text-align: left;">Informational</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19668">Remediated</a></td> </tr> <tr> <td style="text-align: left;"><a href="#tob-pypi26-10-wheel-metadata-is-served-to-installers-without-validation-against-upload-metadata">TOB-PYPI26-10</a></td> <td style="text-align: left;">Wheel METADATA is served to installers without validation against upload metadata</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">Accepted</td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-11</td> <td style="text-align: left;">IDOR in API Token Deletion Allows Any Authenticated User to Delete Other Users' Macaroons</td> <td style="text-align: left;">Low</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19669">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-12</td> <td style="text-align: left;">GitHub OIDC publisher lookup lacks issuer URL isolation for custom GHES issuers</td> <td style="text-align: left;">Informational</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19661">Remediated</a> <a href="https://github.com/pypi/warehouse/pull/19661">1</a>, <a href="https://github.com/pypi/warehouse/pull/19718">2</a></td> </tr> <tr> <td style="text-align: left;"><a href="#tob-pypi26-13-organization-scoped-project-associations-persist-after-project-transfer-or-removal">TOB-PYPI26-13</a></td> <td style="text-align: left;">Organization-scoped project associations persist after project transfer or removal</td> <td style="text-align: left;">High</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19749">Remediated</a></td> </tr> <tr> <td style="text-align: left;">TOB-PYPI26-14</td> <td style="text-align: left;">Admin flag changes lack audit logging</td> <td style="text-align: left;">Informational</td> <td style="text-align: left;">High</td> <td style="text-align: left;"><a href="https://github.com/pypi/warehouse/pull/19751">Remediated</a></td> </tr> </tbody> </table> <p>Of the 14 findings, I used a combination of Severity and Difficulty to determine which ones to work on first, and which ones to accept for now.</p> <p>There were 2 High, 1 Medium, 7 Low, and 4 Informational severity findings.</p> <p>All but 2 findings have been remediated, and the remaining 2 are accepted for now. More details on the accepted findings below, but in general these were accepted because they require significant effort to remediate, and the risk they pose is relatively low.</p> <p>To reiterate, the <a href="https://github.com/trailofbits/publications/blob/master/reviews/2026-04-pypi-warehouse-securityreview.pdf">published report PDF</a> goes into deeper detail about each finding, so I recommend reading that for the fullest context first.</p> <h2 id="details">Details</h2> <p>For some of the Remediated entries and all the Accepted ones, I'll go into more detail below.</p> <h3 id="tob-pypi26-1-oidc-jti-anti-replay-lock-expires-before-jwt-leeway-window-closes">TOB-PYPI26-1: OIDC JTI anti-replay lock expires before JWT leeway window closes</h3> <p>PyPI's <a href="https://docs.pypi.org/trusted-publishers/">Trusted Publishing</a>
…