pypi

Bilingual

A quote from Seth Larson
2 months ago
- PyPI now blocks new file uploads to releases older than 14 days.
- This restriction prevents poisoning of old and stable releases in case of compromised tokens or workflows.
- The abuse hasn't been observed yet, but was technically possible without this measure.
- The change was announced by Seth Larson on the PyPI blog on 23rd July 2026.
PyPI now rejects new files after 14 days
2 months ago
- PyPI now rejects new files uploaded to releases older than 14 days to prevent poisoning of old releases if publishing tokens or workflows are compromised.
- The policy discussion began during PEP 740 (Digital Attestations) in January 2024 and was restarted after the LiteLLM and Telnyx packages were compromised in March 2026 due to a mutable reference in the Trivy GitHub Action.
- Some projects relied on the ability to add support for new Python versions to already-published releases, but a PyPI database query showed only 56 of the top 15,000 packages published a 3.14-compatible wheel more than 14 days after a release.
PyPI Blog: Releases now reject new files after 14 days
2 months ago
- PyPI now rejects new file uploads to releases older than 14 days to prevent poisoning of old releases in case of compromised tokens or workflows.
- The restriction has not been abused yet but there was no technical barrier preventing it.
- Users should not rely on this behavior as semantics for 'closed' releases and APIs are not yet defined; they will be standardized under PEP 694 (Upload 2.0 API and Staged Previews).
- The discussion started during PEP 740 in January 2024 and was restarted in March 2026 after compromises of LiteLLM and Telnyx due to a mutable reference in the Trivy GitHub Action.
- To gauge disruption, PyPI database queries showed that only 56 of the top 15,000 packages had published a Python 3.14 wheel more than 14 days after the release.
- The Packaging Summit at PyCon US 2026 reached rough consensus that requiring users to bump versions for new Python support was acceptable, leading to a patch merged on July 8, 2026.
- This change protects users, reduces cleanup work for PyPI admins, and prevents releases from being in an indeterminate state where only some files are compromised.
- The work by Seth Larson and Mike Fiedler is supported by Alpha-Omega.
Planned Updates to the PyPI User Interface
2 months ago
- PyPI is introducing a new 'Security' tab to centralize provenance and attestation metadata, with indicators for missing or changed provenance.
- Navigation will move from the sidebar to horizontal tabs, reserving the sidebar for metadata.
- The metadata sidebar will shift to the right, aligning the package description/readme on the left for better readability.
- Trust levels will be explicitly labeled to help users evaluate data source trustworthiness.
- Sidebar metadata will be reordered by utility, prioritizing links and freshness signals.
- Clearer status labeling with bolder colors will distinguish quarantined, yanked, archived, and pre-release states.
- Updates are visual only and require no action from maintainers; existing attestations will map automatically.
- The rollout has four phases: Project Details (live on TestPyPI), Files and Release History, Security Tab, and Documentation Refresh.
- Community feedback is welcome via GitHub issues, with detailed bug reports including browser and device info.
- The updates are based on user research and the OpenSSF style guide for attestations, with contributions from user interviews and a survey of 777 people.
How to publish to PyPI using GitHub Actions securely
2 months ago
- Implement zizmor to analyze and secure GitHub Actions workflows by fixing insecure defaults and adding it to CI.
- Use Trusted Publishing for PyPI to avoid managing API tokens and leverage GitHub's security.
- Require approval for publishing workflows via GitHub environments to prevent accidental or malicious releases.
You shouldn't trust Trusted Publishing
2 months ago
- Trusted Publishing is an authentication scheme for machine-to-machine trust, not for human trust in package safety.
- It uses OIDC to link CI/CD machine identities to package indexes, issuing short-lived, scoped publishing credentials.
- PyPI avoids displaying Trusted Publishing status prominently to prevent misuse as a trust signal for package quality.
- Trusted Publishing reduces long-lived credentials but can still be compromised if CI/CD workflows are attacked.
- The scheme is optional and does not guarantee package safety; anyone can use it, including for malicious uploads.
- Attestations on PyPI are separate from Trusted Publishing and also do not imply end-user trust without independent verification.

A quote from Seth Larson

PyPI now rejects new files after 14 days

PyPI Blog: Releases now reject new files after 14 days

Planned Updates to the PyPI User Interface

How to publish to PyPI using GitHub Actions securely

You shouldn't trust Trusted Publishing