PyPI 新规：发布 14 天后拒绝新文件
PyPI Blog: Releases now reject new files after 14 days
PyPI 刚刚实施了一项关键安全更新：任何发布超过 14 天的版本将不再接受新文件上传。这一举措旨在防止像 LiteLLM 和 Telnyx 那样的供应链攻击，避免旧版本被恶意篡改。尽管部分项目曾依赖此机制来为旧版本添加新 Python 版本支持，但数据显示仅有极少数项目受影响。经过 PyCon US 2026 的讨论与共识，社区决定要求用户通过升级版本来适配新环境，而非无限期开放旧版本。未来，随着 Upload 2.0 API 和 PEP 694 的标准化，PyPI 将提供更明确的“封闭发布”语义，进一步保障生态安全。
这一限制意味着，即使项目遭遇入侵，也不会让发布状态陷入既“已受损”又“未受损”的混乱局面，从而避免只有部分文件被植入恶意代码的情况。
- yladiz
我有点惊讶这竟然一开始就是可行的。我理解你可能无法一次性上传所有内容，但在这种情况下，感觉应该有一个“开始”和“完成”发布的过程，一旦完成发布，就不应再允许修改。
我想到的使用场景可能是：你想为旧版本的发布构建一个适用于新 Python 版本的 wheel 文件？
- firesteelrain
这看起来像是常识性的配置管理 101。如果我下载了 v1.2 且它已经发布，那么它就应该被视为已发布且不可修改。当然，'dev' 发布版本除外。我从未在 PyPI 上发布过任何东西，但我预计会有一个发布按钮和一个（可选的）最终确认按钮，如果 14 天后未勾选该选项，发布就会自动变为最终状态？
- edelbitter
> 为了量化这一变更对现有工作流程的破坏程度，我们查询了 PyPI 数据库，统计了那些向旧版本发布新文件的项目
虽然这可能量化了该变更对那些能够并确实会在之后向 PyPI 上传额外二进制文件的项目的破坏程度，但它未能量化有多少项目在该限制引入之前就已经完全绕过了它。
例如，如果你告诉 pip 从源码安装，结果可能就是你安装了一个 PyPI 从未见过的二进制文件。这是一种处理 NVidia 内部组件的常见技巧，这些组件可能爆炸成巨大的 CUDA 主版本 x GPU 架构 x 平台 x 实现 x python_version 的笛卡尔积。"extras" 机制不足以建模此类组合。
示例代码：
https://github.com/Dao-AILab/causal-conv1d/blob/4f6ae4e26ae5...