PyPI 实现可复现构建还缺什么？
What's missing to have reproducible builds on PyPI
在撰写 2026 年 Python Packaging Council 提名材料时，我意识到安全供应链中缺失的关键一环是可复现构建。这不仅能验证分发包是否被篡改，还能追溯构建工具是否被植入恶意代码，正如 SolarWinds 事件所警示的那样。目前，wheels 虽支持记录软件物料清单（SBOMs），但 sdists 却缺乏类似机制来记录构建环境。若能在元数据中明确记录源代码位置和构建工具，配合可信验证者将复现结果反馈给 PyPI，我们就能在无需开发者额外工作的情况下，显著提升生态安全性。这不应是强制要求，而是值得推广的加分项。
可复现构建能让独立的第三方验证分发包中的二进制文件是否与基于源代码的预期结果一致，从而检测构建过程中是否有人篡改了代码。
HN 评论区
10- edelbitter
> 该文件由 <可信方名称> 独立复现
听起来风险很大，除非配合一套关于验证者该如何行事的强有力政策。
例如，如果验证者只是给构建机器人（buildbot）开放网络访问权限，然后让它检查结果应该是什么样子，那么一旦遭到入侵，问题可能依然隐形，而标签则会悄无声息地降级为“由某方独立下载”。
而且我不认为除了自身需求外，会有太多机构愿意提供此类服务，尤其是那些基础设施和政策已经到位的地方（比如 Debian），它们本就已经在提供这项服务了。或者至少，它们本就应该为那些不会在每个版本更新时都破坏可复现性的构建依赖做出贡献。
- whateverboat
对于 Python 来说，要想以真正有用的方式实现可复现构建似乎非常困难，因为 Python 的 wheel 包对路径和环境有着非常隐式的假设，而这些假设在其他地方根本不存在。
- crabbone
这些人已经彻底活在自己的幻想世界里了……
> 所以我们要么耸耸肩说：“如果你想要可复现构建，就别用 sdist。”
这是什么鬼话，我简直无语了……如果下载的是源代码，怎么可能指望得到可复现构建的产物？
现在，最重要的是，所有这些讨论都只针对“纯”（即仅 Python 编写）包。实际上，这对大多数真实的 Python 项目毫无价值，因为它们都依赖原生绑定。如果连构建这些绑定的标准流程都不存在，为什么还有人指望 PyPI 能构建它们，这简直令人无法理解。