Debian forky 新规则：不可复现包将被挡在 testing 外

Debian 这次动的是一条很具体的线：包还能不能进 testing。

Debian Release Team 在 2026 年 5 月 10 日的 “bits from the release team” 邮件中说，forky 发布周期已经走到大约一半。由 Paul Gevers 代表发布团队发出的这封邮件提到，项目已从 5 月 9 日左右开始，在迁移软件中启用新规则。

规则不复杂：无法复现构建的新上传包会被挡住；已经在 testing 中、但复现性发生退化的既有包，也会被挡住。

我更在意的是后半句。Debian 没有只盯新包，也没有把可复现构建停在倡议层面。它开始用迁移机制告诉维护者：能编译、能测试，还不够；二进制产物能不能被独立复现，也会影响包的去向。

新规则到底挡什么

这项规则依托 Reproducible Builds 项目和 reproduce.debian.net。

可复现构建说白了，是让同一源码、同一构建规则和环境，得到一致的二进制结果。它不直接回答“软件有没有漏洞”。它回答的是另一个问题：用户拿到的二进制，是否真能追溯到对应源码。

这次变化可以压成一张表：

边界也要说清。

Debian 没有宣布所有软件包已经 100% 可复现。邮件里也没有给出受阻包数量、整体复现率，或新的发布时间表。把它写成“Debian 已经完成可复现构建”，就是过度解读。

更准确的说法是：Debian 开始把复现性放进迁移闸门。过去网页上的红点，现在可能变成包进不了 testing 的理由。

为什么这件事对供应链安全重要

开源世界长期靠源码公开、维护者签名、构建基础设施和社区审查建立信任。这套机制仍然重要，但它有一个缝隙：源码可信，不等于用户安装的二进制一定可追溯。

可复现构建补的是这个缝隙。

第三方可以用同一源码重建，再和官方二进制对照。如果结果一致，信任链更硬；如果不一致，至少有地方可查。千里之堤，先看蚁穴。供应链安全很多时候不是靠一句“我们可信”，而是靠能不能复验。

Debian 的难点在规模。

Nix、Guix 这类系统天然更强调构建可追溯性。Arch、Fedora、openSUSE 等发行版也有各自的构建和签名体系。Debian 的特殊处在于包多、架构多、维护者生态分散。把复现性放进 testing 迁移规则，影响的不是少数安全敏感包，而是日常打包流程。

对关注 Linux 供应链安全的开发者，这件事的信号很明确：发行版信任正在从“源码开放”继续往“构建可验证”走。

对企业团队，影响要分场景看。如果你用的是 Debian stable，这封邮件本身不是一次安全补丁，也不是现有稳定版策略变更。如果你维护内部镜像，或基于 testing / unstable 做开发环境，就要给迁移延迟留余量。一个包短期没进 testing，不一定是上游停更，也可能卡在复现性、CI 或多架构队列上。

维护者接下来要改什么

维护者面对的不是“多看一个网页”这么简单。

Paul Gevers 在邮件中还提到两个会放大迁移压力的变量。一个是迁移软件今年早些时候加入了对 binNMU 运行 autopkgtest 的能力。另一个是两周前 Debian archive 新增 loong64 架构。

loong64 加入后，多架构重建和 CI 队列都会变重。Debian 又只允许 buildd 构建出的二进制迁移。叠加 multi-arch 要求，很多包要等待更多架构上的构建、测试和检查。

维护者最直接的动作有三类：

• 上传前看 reproduce.debian.net，别等迁移被挡后才找原因。
• 排查常见不可复现来源，比如构建时间戳、文件排序、路径泄露、随机生成内容。
• 遇到迁移延迟时，同时看 build log、CI 队列、反向依赖 autopkgtest 和架构状态。

发布团队也提醒，源码包上传者有责任确保包最终迁移。如果被反向测试依赖的 autopkgtest 回归挡住，上传者应提交对应的 RC 级 bug。

这句话对维护者很重。它把迁移责任从“我这个包能构建”推到“我这个上传是否能在发行流程里闭环”。包本身、反向依赖、binNMU、多架构状态，都可能变成同一条等待链。

接下来最该看的，不是某个包被挡了几天。

真正要看的是三件事：Debian 会怎样处理临时例外；不可复现问题和 FTBFS 问题谁先排；loong64 带来的队列压力会不会让维护者低估迁移时间。

如果规则执行太软，它会退回一条倡议。如果执行太硬，维护者负担和 testing 拥堵会抬头。Debian 这次选择把问题前移，让它在 testing 前暴露，而不是拖到发行候选阶段集中清账。

这才是这封邮件的分量。