Debian 2026 年强制要求可复现构建：维护者现在该做什么

预计阅读时间：9 分钟

Debian 发布团队做了一个硬性决定：从 2026 年 5 月 11 日起，无法复现构建的新软件包将被迁移系统阻止进入 testing，已有软件包如果出现可复现性退步也会被拦下。这意味着"可复现构建"不再是加分项，而是准入门槛。

可复现构建到底在解决什么问题

可复现构建的定义很直接：在相同的 Debian 构建环境中，对同一个源码包执行两次构建，产出的二进制包逐字节完全一致。

听起来像是学术追求，但它解决的是真实的安全问题。假设一个攻击者入侵了构建服务器，在编译过程中悄悄注入了恶意代码。如果构建不可复现，你无法通过重新构建来验证官方发布的二进制是否被篡改——因为你本来就预期每次构建结果不同。而可复现构建让任何人都可以从源码重新构建，然后与官方包做逐字节比对，一旦不一致就能确认有问题。

此外，它还带来工程上的好处：构建缓存更可靠，分布式构建可以互相验证，审计和追溯也变得可行。

为什么构建会不可复现

构建结果不一致的常见原因比很多人想象的更琐碎：

时间戳嵌入：编译时把当前时间写进了二进制或文档
文件系统排序：find、ls 等命令的输出顺序依赖底层文件系统实现
随机性：构建脚本中调用了 /dev/urandom，或编译器使用了随机化优化策略
路径依赖：构建路径（如 /build/package-1.0/）被硬编码进了产物
语言特定问题：Python 的 .pyc 文件包含构建时间戳，Rust 的 panic 信息可能包含源码绝对路径

Debian 的可复现构建项目已经维护了一份详尽的常见原因清单，但核心思路是：把所有不确定的输入固定下来。

2026 年的硬门槛具体怎么运作

Debian 的迁移系统（Britney）负责把软件包从 unstable 迁移到 testing。目前迁移条件包括：没有严重 bug、依赖可满足、在所有必需架构上成功构建。

2026 年 5 月之后，Britney 会新增一条规则：

新上传的软件包，如果在其架构上被标记为不可复现，迁移将被阻止
已在 testing 中的软件包，如果新版本的可复现性状态从"可复现"退步为"不可复现"，迁移也会被阻止

这不是说不可复现的包会被立刻从 unstable 删除，而是它无法进入 testing，进而无法进入正式发布版。对于维护者来说，这等于你的包停在了发布流水线的入口处。

让你的包可复现：实操步骤

下面是一套可以直接在本地跑的验证流程，以一个假设的 mytool 软件包为例。

第一步：固定构建环境的关键变量

在 debian/rules 中设置 SOURCE_DATE_EPOCH，这是可复现构建的基石变量，几乎所有支持可复现构建的工具链都会读取它：

# debian/rules
export SOURCE_DATE_EPOCH = $(shell dpkg-parsechangelog -S Date | date -u +%s)

# 如果你的包用 dh 做默认构建，上面这一行通常就够了
# 如果有自定义步骤，确保不直接调用 date 命令获取当前时间

%:
    dh $@

SOURCE_DATE_EPOCH 把"当前时间"替换为 changelog 中最后一次修改的时间戳，这样每次构建都使用同一个时间值。

第二步：处理文件排序不确定性

如果你的构建过程会打包目录内容，确保排序是确定性的：

# 不要这样——输出顺序依赖文件系统
find src/ -type f > filelist.txt

# 改成这样——强制排序
find src/ -type f | LC_ALL=C sort > filelist.txt

在 debian/rules 中可以全局设置：

export LC_ALL = C

第三步：用 diffoscope 验证可复现性

diffoscope 是 Debian 可复现构建项目的核心验证工具，能深入比较两个包的每个差异：

# 安装 diffoscope
sudo apt install diffoscope

# 第一次构建
dpkg-buildpackage -b

# 保存产物
mkdir -p /tmp/repro-test/first
cp ../mytool_*.deb /tmp/repro-test/first/

# 清理并第二次构建
fakeroot debian/rules clean
dpkg-buildpackage -b

# 保存第二次产物
mkdir -p /tmp/repro-test/second
cp ../mytool_*.deb /tmp/repro-test/second/

# 比较两次构建结果
diffoscope /tmp/repro-test/first/mytool_1.0-1_amd64.deb \
           /tmp/repro-test/second/mytool_1.0-1_amd64.deb

如果输出为空或只显示"identical"，你的包就是可复现的。如果有差异，diffoscope 会精确指出哪个文件的哪个字节不同，以及差异的语义含义（比如"这是一个时间戳字段"）。

第四步：在线验证

Debian 已经有持续运行的可复现构建测试基础设施。你可以直接查看自己包的状态：

# 查看包在可复现构建仪表盘上的状态
# 替换 PACKAGE 为你的包名
curl -s "https://tests.reproducible-builds.org/debian/rb-pkg/PACKAGE.html" | \
  grep -E 'reproducible|FTBFS|unreproducible'

或者直接在浏览器中访问 https://tests.reproducible-builds.org/debian/rb-pkg/<包名>.html，查看两次构建的详细对比报告。

维护者行动清单

距离 2026 年 5 月还有时间，但越早处理越从容：

查状态：在可复现构建仪表盘上找到你的包，确认当前标记是 reproducible 还是有问题
跑 diffoscope：本地做两次构建并比较，这是最直接的验证方式
修常见问题：设置 SOURCE_DATE_EPOCH、LC_ALL=C，检查是否有硬编码路径和时间戳
关注架构差异：有些包在 amd64 上可复现但在 arm64 上不行，通常是因为编译器版本或默认行为不同
上传前验证：每次新版本上传前，确认可复现性没有退步

对于已经标记为可复现的包，维护者需要做的是防止退步——新版本引入了新的时间戳或路径依赖就会导致退步，而 Britney 会拦住它。对于尚未可复现的包，2026 年的硬门槛意味着现在就要开始排查和修复。

可复现构建从"理想"变成了"必选项"。Debian 的这个决定，本质上是在用发布流程的准入机制倒逼整个生态正视供应链可信度的问题。