在 PyPI 上实现可重复构建缺少什么？

# 如何在PyPI上实现可重复构建？还缺少什么 来源：https://snarky.ca/whats-missing-to-have-reproducible-builds-on-pypi/ 2026年8月15日 | 阅读约4分钟 | Python (https://snarky.ca/tag/python/) 在为2026年Python包装委员会（PPC）提名声明（https://snarky.ca/my-nomination-statement-for-the2026-python-packaging-council/）撰写“安全供应链”章节时，我意识到在构建安全供应链方面，我们目前缺少一种明确的方法来实现可重复构建（https://reproducible-builds.org/）。我喜欢可重复构建的理念，是因为它可以在设计上无需分发产物（这是对sdist（https://packaging.python.org/en/latest/specifications/source-distribution-format/）或wheel（https://packaging.python.org/en/latest/specifications/binary-distribution-format/）的技术统称，即上传到PyPI的东西）的生产者进行任何额外操作，从而使支持可重复构建变得非常简单。 ## 为什么你应该关注 从安全供应链的角度看，可重复构建允许独立的第三方验证分发包中的内容是否与构建该分发包的源代码所预期的匹配。这让你有可能检测到是否有人在构建过程中篡改了代码。此外，由于必须记录构建过程中涉及的软件，即使你没有进行所有必要的验证来确保内容完全一致，也能更容易地检测到是否使用了已知被入侵的工具。这并非假想的益处——SolarWinds（https://www.cisa.gov/eviction-strategies-tool/dialog-content/TMPL0002）就是因为构建过程被注入恶意代码而遭到入侵的。 不要因为“构建”这个词而误以为纯Python的wheel不会受到威胁。构建wheel需要使用构建后端（https://packaging.python.org/en/latest/specifications/pyproject-toml/#declaring-build-system-dependencies-the-build-system-table），如果这个构建后端被入侵，它可能会在wheel中注入恶意代码。因此，Python包管理中的任何领域都不能忽视这些风险。 ## 规范中缺失的部分 ### 源代码在哪里？ 那么，在Python包管理中我们需要什么才能实现可重复构建？首先，我们需要记录使用了哪些源代码。这在sdist或wheel中并没有被记录，但如果你直接从源代码仓库或归档文件安装，安装器会在`direct_url.json`（https://packaging.python.org/en/latest/specifications/direct-url/）中记录这些信息。如果我们在sdist和wheel中记录相同的信息（例如在元数据中），就能知道用于构建该分发包的源代码位置。 ### 构建分发包使用了什么软件？ 但下一个棘手的问题是记录创建分发包所使用的所有工具。对于wheel，我们支持记录软件物料清单（SBOMs）（https://packaging.python.org/en/latest/specifications/binary-distribution-format/#the-dist-info-sboms-directory）。正如添加这一支持的PEP 770（https://peps.python.org/pep-0770/#build-tools-environment-and-reproducibility）（声明：我是该PEP的负责人）所说，SBOMs可用于记录构建分发包时使用的构建工具（https://peps.python.org/pep-0770/#build-tools-environment-and-reproducibility）。如果你记录了构建分发包所用的所有软件，就有望重现完全相同的内容，并证明没有发生任何篡改。 不幸的是，sdist没有类似的机制来记录SBOMs。由于sdist通常只是一个包含PKG-INFO文件（其中包含一些预先计算的元数据）的tarball，没有地方放置其他元数据文件。因此，我们只能耸耸肩说：“如果想要可重复构建，就别用sdist”，或者我们将不得不设计一种允许更多结构化数据的sdist v2格式。 ### 谁来记录使用了什么软件？ 现在，你可能想知道即使拥有所有这些信息，该如何重现构建。幸运的是，由于我们在pyproject.toml中有`[build-system]`表，我们有一个明确定义的入口点来调用生成分发包的构建后端。这意味着一旦我们记录了运行构建后端所需的所有软件，我们就可以通过安装相同的内容并按照`[build-system]`的定义调用构建后端来重放构建过程。如果构建后端能负责记录其运行环境中安装的软件，理论上我们可以将构建后端使用的所有软件记录在SBOMs中，而无需分发生产者进行额外操作（但这确实会给pip维护者带来工作）。 ## 在PyPI上体现可重复性 假设所有这些都得以实现，我们记录了源代码的位置和构建分发包所使用的软件，如何让人们从中受益？每个关心安全供应链的人都必须自己重新构建所有使用的东西吗？有没有一种方式让不关心这些事情的人也能受益？ 一种可能的方式是引入可信的验证者，当他们成功重现一个分发包时，可以通知PyPI。由于各家企业无论如何都会这样做，他们可以将这些信息反馈给PyPI，从而明确标注某个分发文件“已被××独立重现”。这意味着用户可以得知某个分发包符合创建者的预期，而验证者也能因帮助社区而获得一些认可。这甚至可以在索引API（https://packaging.python.org/en/latest/specifications/simple-repository-api/）中体现，以便安装器可以优先选择已重现的分发包。 这样做时，不应让任何碰巧没有使用能够创建可重现分发包的构建后端的人感到难堪。这始终应被视为一项附加优势而非强制要求。这就像能够声明你的项目达到了SLSA的构建级别1（https://slsa.dev/spec/v1.2/build-requirements#build-levels）（上述所有内容都满足此级别）；有些人喜欢这样说，但这并不是对选择不关注这些事情的人的贬低。 ## 致谢 感谢Seth Larson倾听我的想法并审阅这篇博客文章。