PyPI 发布版本现在在14天后拒绝新文件上传

# 发布版本现拒绝14天后上传新文件 - Python 包索引博客 来源：https://blog.pypi.org/posts/2026-07-22-releases-now-reject-new-files-after-14-days/ 安全 (https://blog.pypi.org/tags/#tag:security) Python 包索引 (PyPI) 现在拒绝向超过14天的发布版本上传新文件。此项限制 (https://github.com/pypi/warehouse/pull/19727) 是为了防止在 PyPI 项目的发布令牌或工作流遭到泄露时，旧且长期稳定的版本被投毒。据我们所知，目前尚未发现此行为被滥用，但除了攻击者不知道这是可行的之外，没有其他技术原因。 用户目前不应依赖此行为，因为尚未定义“不再接受新文件的发布版本”的语义，也没有可用于确认发布状态的 API。相反，这些语义将在“Upload 2.0 API”和“Staged Previews”通过 PEP 694 (https://peps.python.org/pep-0694/) 标准化后定义。 此行为的讨论始于2024年1月 PEP 740（数字认证）期间 (https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566)。在流行软件包 LiteLLM 和 Telnyx 遭到入侵后 (https://blog.pypi.org/posts/2026-04-02-incident-report-litellm-telnyx-supply-chain-attack/)，讨论于2026年3月重启 (https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/34)。这些软件包之所以被入侵，是因为这些项目在 Trivy GitHub Action 的使用中存在“可变引用 (https://mikael.barbero.tech/blog/post/2026-03-24-stop-trusting-mutable-references/)”问题。 最初，由于某些项目依赖此行为来为已发布的版本添加对新 Python 版本的支持，讨论陷入了停滞。为了量化这一变化对现有工作流程的破坏程度，PyPI 数据库被查询了那些向旧版本发布新文件的项目 (https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/48)（按发布后的天数分桶）。随后，特别针对前15000个包查询了 `cp314` 轮子，结果显示，在15000个项目中，只有56个项目 (https://discuss.python.org/t/restricting-open-ended-releases-on-pypi/43566/63) 在发布版本超过14天后发布了兼容3.14的轮子。 PyPI 安全与保障工程师 Mike Fiedler 在 PyCon US 2026 的打包峰会上 (https://hackmd.io/k0C-RAIVRnu-YXoDFgABvA) 提出了这一话题。讨论的粗略共识是，峰会参与者认为“要求用户升级到下一个版本”以支持新 Python 版本是可以接受的。基于数据和共识，Seth 推进了一个补丁 (https://github.com/pypi/warehouse/pull/19727)，拒绝向旧版本上传新文件，该补丁于2026年7月8日合并。 这一变化将保护 Python 用户，并减少 PyPI 管理员因项目被入侵而需要进行的“清理”工作。此限制还意味着，入侵不会使发布版本处于既“被入侵”又“未被入侵”的不确定和混乱状态，即只有部分文件可能被恶意软件投毒。敬请期待未来的 Upload 2.0 API，它将为“已关闭”而非“开放”的发布版本提供语义。 Seth Larson 和 Mike Fiedler 在 Python 软件基金会的工作得到了 Alpha-Omega (https://alpha-omega.dev/) 的支持。