LWN：可再现构建的历史、现状与规划！

关注了就能看到更多这么棒的文章哦～

The history, status, and plans for reproducible builds

By Jake Edge
August 23, 2024
DebConf
Gemini-1.5-flash translation
https://lwn.net/Articles/985739/

在韩国釜山举行的 DebConf24 大会第二天，Holger Levsen 为我们带来了关于“再现构建项目（Reproducible Builds project）的前 11 年”的历史回顾。他参与了该项目的大部分时间，并且从 1990 年代中期开始使用 Debian，从 2001 年开始贡献，并在 2007 年成为 Debian 成员；“我热爱 Debian”。与此同时，他的目标是让所有自由软件都可再现，这样任何人都可以验证二进制程序是否来自其声称的源代码。

他首先指出，这次演讲并非完全是他个人的，而是源于 超过 100 人 在再现构建网站上所做的工作。他向观众提出了一些问题，例如谁知道该项目，谁为它做出了贡献，以及谁知道该项目本身虽然存在了十多年但其实再现构建的想法可以追溯到 30 多年前？他说，这次演讲的目标是回顾和庆祝已经取得的成果，以激发与会者的热情，从而让他们参与到该项目中。“因为还有很多工作要做。”

问题在于，虽然自由软件的源代码是可用的，但大多数人安装的是预编译的二进制文件。“没有人真正知道它们是如何对应的，即使是构建二进制文件的人。”例如，执行构建动作的机器可能已被入侵，这样就可能会导致各种类型的供应链攻击。

历史概述

他回顾了一些“古代历史”，指出早在 2007 年的一个 debian-devel 邮件列表帖子 中，人们就提出了这个想法。当时人们的反应并不热烈；一些人认为没有益处，另一些人则认为技术上不可行。实际上，早在 2000 年，这个想法就在列表中出现过。在 2017 年的再现构建 rb-general 邮件列表中，John Gilmore 指出，GCC 和相关工具可以在 1990 年代初期以可再现的方式构建，但这种能力已经衰退。

“快进到去年”，在 WireGuard 邮件列表上出现了一篇 帖子，指出该项目的 Android VPN 应用可以以可再现的方式构建。WireGuard、F-Droid 和 Google Play 商店都产生了相同的二进制文件。此外，WireGuard 项目从未通知再现构建项目他们正在进行这项工作；这让他很高兴，因为这意味着构建可再现的构建如今只是某些项目作为一项惯例所做的事情。

再现构建项目 定义 了该术语，如下所示：“如果在给定相同的源代码、构建环境和构建说明的情况下，任何一方都可以重新创建所有指定构件的逐 bit 位都相同的副本，那么构建就是 可再现的 。”它接着说，环境和说明由包的作者指定，而构件是构建的“期望的初级输出”。

该项目的使命是使任何人都能验证给定源代码是否会产生逐位相同的結果。“我们不想要‘Debian 认为软件是可再现的’这样的说法，你们中的每一个人都应该能够独立地确认这一点。”可再现构建是使供应链更安全的关键组成部分，但它们并不能使不安全的软件变得安全。它们只是确保“你正在运行你想要运行的软件”。

如今，可再现构建更加广为人知。该项目网站列出了 演讲和其他资源、学术出版物，以及在其 文档页面 上的许多其他信息。2021 年，美国总统发布了一项 行政命令，特别提到了随软件一起提供的 软件物料清单 (SBOM) 的要求，以便用户可以确定其二进制文件中包含的内容；SBOM 也是可再现构建所必需的。

“那么，我们是如何走到这一步的？”他说，金钱是一个因素。Bitcoin 软件是在 2011 年变得可再现的，早于 Debian 开始进行可再现构建的工作，当时所有 Bitcoin 的总价值约为 40 亿美元。Bitcoin 开发人员担心后门二进制文件会窃取所有这些钱，并且他们会因此受到指责，所以他们使软件实现了可再现能力。

Levsen 说，另一个因素是 Edward Snowden。Tor 浏览器在 2013 年变得可再现，部分原因是 Snowden 发布的信息。Tor 浏览器基于 Firefox，“全球最大的”软件项目之一，他表示，它的二进制文件大小为 50MB。然而，除了金钱和 Snowden 之外，还来源于“许多人在多年时间里的辛勤工作”。

Debian

在 2013 年的 DebConf13 上，Jérémy Bobbio（也称为“Lunar”）主持了一个头脑风暴会议，这个会议受到了 Tor 浏览器可再现性的成功的启发；在 DebConf14 上也进行了一次类似的会议。Levsen 问房间里是否有人参加了 2013 年的会议，但没有人，包括他自己。在 2014 年的 FOSDEM 上，Bobbio 在 Debian 的开发人员房间（devroom）中发表了关于 Debian 可再现构建的演讲。

dpkg 的第一个补丁出现在 2014 年；它们包括修复数据和控制文件中元素的排序顺序，以及创建 .buildinfo 格式，这实际上是一种 SBOM 格式。 .buildinfo 文件包含关于环境、源代码、用于构建包的工具的哈希值等所有信息。

2014 年 9 月，Levsen 开始对 Debian 包进行系统构建，以检查其可再现性。他在 2014 年 12 月的 Chaos Communication Congress 上，作为了 Tor 项目的 Mike Perry 和 Seth Schoen 的演讲听众，当时他们使用了“他”的 Debian 包进度图：“哇”。这场演讲显然引起了 Levsen 的共鸣，因为他花了一些时间展示了 幻灯片，并回顾了他们提出的一些观点。

2015 年，Bobbio 和 Levsen 共同在 FOSDEM 上发表了演讲，邀请所有自由软件界人士共同解决可再现构建问题。他们意识到，如果不仅仅是 Debian 在研究它，那么让其他项目参与进来很重要。Bobbio 在 2015 年的 Chaos Communication Camp 上发表了演讲（幻灯片），“展示了许多问题及其解决方案”，以使软件能够以可再现的方式构建；这场演讲在今天仍然有用。

Levsen 说，使代码无法以可再现方式构建的主要原因是“时间戳和时间戳，还有更多的时间戳”，“软件喜欢时间戳”。另一个问题点是构建路径。时间戳问题通过 SOURCE_DATE_EPOCH 环境变量 基本上已经克服，而构建路径则通过记录和重复使用相同的构建路径来处理。多年来，该项目尝试了不同的构建路径方法，但现在已经决定路径只是构建环境的一部分。当然，还有一些其他问题领域。

构建时间戳基本上没有意义，但它们确实会改变二进制文件。如果设置了 SOURCE_DATE_EPOCH，许多软件，包括所有 Debian 包，都将使用它；它可以设置为源代码最后修改的时间，这确实有一定的意义。他说，许多主要项目，如 GCC、Clang、Python、OCaml 等，都支持使用 SOURCE_DATE_EPOCH 进行构建。它的最初规范是在 2015 年创建的；在 2017 年也进行了小幅更新，“从那时起，它就保持不变”。它是大约 2KB 的文本，“非常短”。

Diffoscope

diffoscope 工具也是在 2015 年出现的；Bobbio 开始将其称为 debbindiff，但一旦它不再是 Debian 专用，它就被重命名了。Diffoscope 试图确定“是什么使文件和目录不同”；它会解压缩存档（如果需要，递归地），并将二进制格式转换为更人性化的形式，以便进行比较。例如，他说，如果你比较两个 .deb 文件，每个文件都包含一个 ar 存档，其中包含多个 tar 存档，其中一个存档包含一个 PDF，其中包含一个 PNG，每个文件都具有不同的时间戳，“diffoscope 会告诉你”。

Diffoscope 提供文本和 HTML 输出。它可以解码大量的格式；他列出的列表横跨两张幻灯片（如 演讲的 WebM 视频 所示），并且已有 1 年历史，所以“可能从那时起又增加了 20 种或更多种文件格式”。它最初只接受两个 .deb 文件进行比较，但现在“你可以将它指向两个目录、两个 ISO 映像、两个任何东西，它都会进行比较”。如果它不知道格式，它会退回到十六进制转储比较。

Diffoscope 也在软件环境之外使用；他遇到了一位律师，他使用它来比较法律的 PDF 文件，以查看文本中做了哪些修改。他展示了 两个版本的 HTTPS Everywhere 浏览器插件的输出示例 。“所以你也可以用它来比较两个不同的软件版本”，以查看所做的更改。Levsen 说，整个包大小约为 1.5GB，以支持所有这些格式，因此它也可以 在网上使用，方法是将文件上传到 Web 应用程序。

他展示了一张图表，显示了这些年来在 Debian 包中修复的可再现性错误。已经修复了将近 4000 个错误，其中大多数已经向上游发布，尽管仍然有大约 300 个补丁正在等待。

除了时间戳和构建路径之外，该项目还发现了 430 种导致不可再现构建的不同问题，这些问题记录在 reproducible-notes 仓库 中。人们经常问“如何使包可再现”，这很难说；更容易说的是什么使包不可再现。为此，该项目创建了 unreproducible 包，“它有很多问题”。

这些年来，该项目对 Debian 包进行的频繁重建也发现了许多其他错误，在过去 11 年中，平均每天大约 9 个错误，大多数是“无法从源代码构建 (FTBFS)”错误。这只是该项目发现的额外好处之一。消除二进制构件的差异意味着构建系统可以更容易地缓存对象，从而提高开发速度，降低开发成本；他说，许多大公司对此很感兴趣。可再现性还有助于验证更改是否真正只产生了预期的效果；只有应该受到影响的二进制文件才发生了更改。

到目前为止，已经举办了七次 可再现构建峰会，九月将举行另一场峰会，他邀请观众参加。他列出了参加峰会的近 70 个项目、组织和公司，但指出也有一些人要求不列出他们的名字。在 2016 年柏林峰会上，人们意外地发现了可再现构建的另一个好处，即 可引导构建 在一个分组讨论中诞生。这个想法是 从源代码引导工具链二进制文件，从手写的机器代码中的最小汇编程序开始，然后逐步构建更复杂的编译器和其他工具。

再现构建项目自 2018 年起成为 软件自由保护协会 (Software Freedom Conservancy) 项目。目前有三个赞助商，使该项目能够资助四个人：Chris Lamb、Mattia Rizzolo、Vagrant Cascadian 和 Levsen。

Levsen 展示了一张图表，显示了 Debian 不稳定包的可再现构建的持续集成 (CI) 系统的完整历史。它显示，在 11 年的时间里，包的数量几乎翻了一番，“而且 Debian 现在更加可再现了”。对于下一个 Debian 版本 Debian 13（“trixie”），只有 764 个不可再现的包，而可再现的包超过 34000 个。

政策

自 2023 年底以来，包的 CI 结果显示在测试迁移页面上，尽管对包的可再现性状态的更改没有惩罚或奖励。在 2025 年，当 Debian 14（“forky”）的开发开始时，发布团队希望对导致可再现包变得不可再现的更改引入惩罚；此外，新包需要在被允许进入测试之前以可再现的方式构建。如果 Debian 离不开一些无法以可再现方式构建的包，可以将它们添加到例外列表中。

2017 年，Debian 政策 发生了改变，要求包 应该 （而不是 必须 ）以可再现的方式构建。他希望发布团队为 forky 制定的两项政策能够在 2025 年添加到政策中，然后是在 2027 年（例如）切换到“必须”，尽管仍然会有一个例外列表。他说，实现 100% 可再现并非真正技术问题；而是一个政治决策。例外列表是实现最终目标的手段，对他来说，最终目标是让所有包都能以可再现的方式构建。

他展示了一张幻灯片，显示了过去几个版本的数字，以及对未来几个版本的预测（或希望）。Trixie 将只有 256 个不可再现的包，而 forky 将有 128 个——没有回归或新的不可再现的包。对于 2029 年的 forky+1，将只有 42 个无法再现的包，所有这些包都在列表中。Forky+2 将在“2031 年或更晚”时达到 0 个。“这是我期待或瞄准的时间表，”Levsen 说。

目前对可再现性进行的测试是在同一个环境中构建两次包，但真正想要的是将构建与项目正在（或已经）分发的包进行比较。snapshot.debian.org 服务器旨在作为所有包的存档，但直到最近，它一直处于故障状态，他说。因此，现在可以重新创建过去使用的相同环境，并构建包；debrebuild 命令现在可以用于完成此操作，因为 snapshot.debian.org 已经恢复正常。

这些年来，还有其他 Debian 构件已经变得可再现。docker.debian.net 上列出的 Docker/podman 镜像已经在大约两年的时间里保持可再现性。他说，cdimage.debian.org 上提供的实时映像最近变得可再现。此外，Debian 安装程序 在理论上是可再现的，但目前没有进行测试。

其他发行版也在进行可再现性工作。Tails 只创建一个 ISO 映像，它在过去的五年里一直保持可再现性。Arch Linux 的包中有 80%-90% 是可再现的，而 SUSE 计划在不久的将来发布一个可再现的版本。NixOS 和 Guix 旨在实现可再现性，因此它们接近于完全可再现。Yocto、F-Droid、Alpine Linux 和 BSD（除了 OpenBSD）都对可再现构建提供了基本支持。他说，虽然看起来 Fedora、Red Hat 和 Ubuntu 不感兴趣，但 Fedora 已经做了一些关于 SOURCE_DATE_EPOCH 的工作，Red Hat “更加怀疑”，而对于 Ubuntu，他“听说过传闻”，但没有具体的证据。

因此，如今许多项目都支持可再现构建，尽管在用户理解方面仍然存在差距。他称之为“理论上或 CI 中可再现”。然而，这在十年前被认为是不可能的，因此这是一个“巨大的成功”。“从理论上讲，我们几乎完成了。实际上，我们已经证明，可再现构建在理论上是可行的。”

对于 Debian 来说，现在需要转向重建者，而不是 CI 构建者，因为 snapshot.debian.org 已经恢复正常；这些结果需要存储在某个地方，还需要制定关于如何使用这些数据的政策。同时，需要继续减少不可再现包的数量；Debian 的每个 1% 的不足大约相当于 300 个包。他回到了 2014 年 Perry 和 Schoen 的演示文稿，展示了它也描述了需要工具来独立确认二进制文件是否与其声称的源代码相对应，以及需要某种外部监控，以确保构建基础设施没有出现任何问题。这就是可再现构建如何从理论走向实践。

问答环节

第一个观众的问题是关于 OpenBSD 在每次启动时对库和二进制文件进行随机化的做法。如果二进制文件在最终用户系统每次启动时都被故意更改，那么构建构件的可再现性有什么意义呢？Levsen 没有直接回答这个问题，但他确实指出 OpenBSD 已经表示他们对可再现构建不感兴趣，因为“他们说‘它没有用’”。他说，OpenBSD 认为其构建系统是安全的，因此该项目不需要可再现构建。

另一个问题是关于不可再现包是否会随着时间的推移而改变，或者是一直是相同的包不断出现。Levsen 说，“变得可再现的包通常会保持可再现性，新的上游版本引入不可再现性的情况非常罕见”。此时，所有必需和构建必需的包都是可再现的，但构建必需包有 96 个不可再现的依赖项（在 5500 个依赖项中）。“它现在可以用一屏内容来显示，但这仍然需要一些工作。”

最后的“问题”是邀请任何可能对帮助云团队使这些映像可再现感兴趣的人参加云 BoF。与会者说，它们是目前为数不多的 Debian 构建构件中尚未实现可再现性的构件。Levsen 说，他将在演讲结束后立即与与会者讨论此事。

总体而言，这场演讲的气氛是积极的，对已经取得的成果感到乐观，但同时也认识到仍需努力。可再现（或“确定性”）构建是帮助确保软件供应链安全的重要工具；这是一个 LWN 这些年来多次关注 的话题。可再现构建的旅程还在继续，但远处的光芒显然越来越强。

[我要感谢 Linux 基金会，LWN 的旅行赞助商，感谢其对前往釜山参加 DebConf24 的协助。]

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～