我一直以为"可复现构建"约等于"供应链安全"。调查之后我才意识到这个等同是被演讲者亲口否定的，而且那句话比我预期的更诚实：Reproducible Builds 网站上写着，"Nothing more, nothing less"（不多，也不少）——可复现构建是验证基础设施，本身不是安全属性；"(不)安全软件即便可复现地构建出来，仍然是(不)安全软件"。
这才是我想写的问题：既然目标是"同一份源码、同样环境，任何人能重建出逐位完全一致的产物"，那 Debian 到底做到了什么程度？为什么一个百分比停在 96% 上不去，而不是直接冲到 100%？
数字本身
– Debian unstable（amd64）约 96% 的源码包→.deb 可复现；该比例已多年稳定维持在 94% 以上。
– Debian bookworm 约 93%，trixie 约 95%——稳定套件略落后于 unstable，因为 backport 的修复在向后传播。
– Ubuntu noble 24.04 的 main 约 89%，universe 约 78%，明显落后于 Debian。
– Arch 约 88%，GNU Guix 和 NixOS 因纯函数设计接近 100%（任何偏差都按 bug 处理），Tails 和 Tor Browser 接近 100%。
（这些数字来自 Big Iron 2026-05 的综述，标注为"代表性而非当日权威值"，逐日变动，以 tests.reproducible-builds.org 为准。）
卡在 96% 的 4%，以及"可复现"为什么是一个动词
两个来源给出了一致且有点反直觉的图景。
第一，那 4% 的不可复现，绝大多数不是核心软件。内核、glibc、openssh、openssl、gcc、systemd 这些关键软件在各类架构上都接近 100%。剩下的尾部分布在维护不到位、上游存在未修复问题的长尾包上。也就是说，"96% 可复现"不等于"96% 可信"，反过来，"不可复现"也不等于"危险"——它只是抵抗验证。
第二，cp io 了。可复现构建不是一个能一次到达、随后躺着享受的状态，而是一种需要持续维护的纪律。Big Iron 明确指出：当 Debian 向下 backport 一个改变了编译器优化输出的修复时，相关包会短暂"脱复现"，直到用新工具链重建。换句话说，数字会来回摆动，你今天测到的 96% 是一个时间点快照，不是终点。这也是为什么它的百分比多年来卡在 94–96%，而不是单调逼近 100%——每一轮工具链升级都在消耗一部分成果，而修复的速度只能勉强追平损耗。
这是我最想说的判断：可复现构建的实质投入，不是一次性把包修干净，而是建立一个"重建—比对—修复—再被打破—再修复"的循环机制。Debian 重建农场、diffoscope（递归拆开任意格式再逐文件 diff）、debrebuild（用 .buildinfo 记录的环境哈希精确重现构建）这些基础设施，才是比那个单一百分比更值钱的东西。buildinfo 文件本身甚至早于"SBOM"这个词的流行——演讲者指出，.buildinfo 是 2014 年设计的，本质就是软件物料清单。
一个我保留的未解决点
政策层面有一个不对称：美国白宫 2021-06 的行政命令要求政府软件必须带 SBOM，但对"可复现构建 / 已验证的 SBOM"目前为止只是"推荐"而不是强制（来自 Holger Levsen 演讲引用的 reproducible-builds.org 资料）。为什么更硬的验证手段只停留在推荐层面？我猜跟维护成本有关——强制可复现等于强制每个发行版长期供养一套重建与比对流水线，这比"生成一份清单"贵得多。这仍是我的推断，不是来源里写的结论。
我原来的前提（可复现构建＝安全）被改写了：它更准确的定位是"让验证成为可能的基础设施"。它不制造信任，它把信任从"你只能相信构建机"变成"你可以自己验证"，这个转变本身有价值，但和"没有后门"是两回事。
✦回复与讨论