PyPI 锁定旧版本发布以防范被盗令牌风险

对于所有在 PyPI 上写代码的人来说，这是个好消息。官方的 Python 包索引现在拒绝为一个超过 14 天的发布版本添加任何新文件。该修复来自 Python 软件基金会的安全开发者 Seth Larson，它堵住了一个以前没人利用过的 PyPI 漏洞......但这个漏洞一直悬而未决。

直到现在，维护者可以在任何版本中添加文件，即使是三年前发布的版本。它方便交付新轮子，但如果发布令牌被盗则很危险。攻击者拿到你的密钥可以把损坏的二进制文件偷偷放进大家下载了很久的稳定版本，而不会触发任何警报。

Larson直言不讳地说：如果它还没被滥用，那只是黑客没意识到这是可能的。

触发点是LiteLLM和Telnyx案例，这两个受欢迎的软件包去年三月通过使用GitHub Action Trivy时的“可变引用”被攻破。另一个供应链的入侵，符合我之前提到的npm上的Shai-Hulud其专用扫描仪

，即使机制不同。自2024年1月以来，围绕PEP 740的讨论中，这个话题一直酝酿，只是它停留在一个非常真实的用例上。事实上，一些项目在旧版本发布后很久才会为新版本的Python添加支持，比如Python 3.14的cp314轮子。

只是数字已经决定了一切。在询问PyPI数据库中15,000个最受欢迎的软件包时，只有56个在发布后超过14天内发布了兼容3.14的轮子。换句话说，1.5万个中只有56个，实在是屈指可数。

PyPI的安全工程师Mike Fiedler将这场争论带到了PyCon美国2026年包装峰会上，结果共识开始动摇。这些项目现在被要求升级到新版本。

之后，不要把这个新安全措施当作保证。没有API可以检查发布是否“封闭”，真正的游戏规则只有通过上传API 2.0和PEP 694提供的分阶段预览才会被确立。

所以目前，它只是一个保护的锁，但并不是真正的信任契约来构建（什么Darty？？）。

不过，好处是立竿见影的，因为当项目被坑时，PyPI管理员的清理工作会减少，也避免了那种分裂状态——一个版本一半被攻破，一半健康，中间藏着几个损坏的文件。

一个旧版本变成冻结块，就这样！

GitHub 已经提出了同样的想法，其发布Immuables。

这使得你的版本甚至被项目维护者无法触碰。

简而言之，供应链攻击者少了一扇门。不错吧？资料来源

（在西蒙·威利森被发现）