Debianが再現不可能なパッケージのtesting移行を止め始めた — ゲートが実際に止めるものと止めないもの

はじめに — 一文だけのポリシー変更と、その文が実際に意味すること
再現可能なビルドとは正確には何か
ストレステストと実際の再現 — 本稿でいちばん重要な区別
reproduce.debian.netはどう動くか
ゲート — britneyが実際に止めるもの
数字 — 2026年5月9日時点
何が再現を壊すのか
正直な限界
では、あなたのCIは何を持ち帰れるか
おわりに
参考資料

はじめに — 一文だけのポリシー変更と、その文が実際に意味すること

2026年5月10日午前4時47分(UTC)、Paul Gevers氏がリリースチームを代表してdebian-devel-announceにメールを投稿しました。件名は素っ気なく「bits from the release team」で、冒頭で本人はこう表現しています — 今はforkyリリースサイクルのちょうど折り返し地点で、「コードとしては小さな一歩だが、コミットメントとしては大きな飛躍」("a small step in code, but a giant leap in commitment")を発表したい、と。

その飛躍の本文は二文でした。

Reproducibility
===============

Aided by the efforts of the Reproducible Builds project [1], we've decided it's
time to say that Debian must ship reproducible packages. Since yesterday, we
have enabled our migration software to block migration of new packages that
can't be reproduced [2] or existing packages (in testing) that regress in
reproducibility.

(「since yesterday」とあるので、実際に有効になったのは2026年5月9日です。)

技術メディアはここから最初の一文だけを切り取りました。Phoronixは「Debian Must Now Ship Reproducible Packages」、The Registerは「Debian 14 cracks down on unreproducible packages」と報じました。見出しだけを読むと、Debianはもう再現不可能なパッケージを一切受け付けない、という話に聞こえます。

ところが後の一文をそのまま読むと、範囲はずっと狭いのです。止まるのは(1)再現しない新規パッケージの移行と、(2)testingにすでにあって再現性が回帰したパッケージの移行。この2つだけです。すでにtestingに座っている再現不可能なパッケージ数百個は、そのままです。

本稿はそのギャップについてです。Debianが実際に何を有効にしたのか、その検査が技術的にどう回るのか、今の数字はどこまで来ているのか、そしてこの事例からあなたのビルドパイプラインが実際に持ち出せるものは何か。

再現可能なビルドとは正確には何か

Reproducible Buildsプロジェクトの定義はこうです。

A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.

ここで重要なのは、3つの条件がすべて「同じ」であるという前提です。同じソース、同じビルド環境、同じビルド命令。この条件のもとでは、誰がビルドしてもビット単位で同じ成果物が出るはずだ、という意味です。再現性とは「どんな環境でも同じ結果」ではなく、「指定された環境を再構成したときに同じ結果」です。この区別が、この先ずっと足を引っ張ります。

なぜやるのか。問題はこうです — 自由ソフトウェアのソースは公開されていますが、ほとんどの人は事前コンパイル済みのバイナリをインストールします。そしてその両者が実際に対応しているかどうかは、誰にも分かりません。バイナリをビルドした本人ですら。ビルドマシンが侵害されていたり、コンパイラがバックドアを仕込んでいたりしたら、ソースをいくら監査しても見つかりません。再現可能なビルドはこの穴を塞ぎます — 複数の独立した当事者が同じソースから同じビットを作り出せれば、配布されたバイナリがそのソースから出たものだと検証できます。

ただし、このプロジェクトが自ら付ける注釈をそのまま伝えるのがフェアでしょう。Holger Levsen氏が5月の発表で使った表現です。

Reproducible Builds are an important building block in making supply chains more secure. Nothing more, nothing less. (Un)secure software build reproducibly still remains (un)secure software.

再現可能にビルドされた脆弱なソフトウェアは、それでも脆弱なソフトウェアです。再現性が保証するのは「このバイナリはこのソースから出た」という点だけであり、そのソースが安全だということは何も保証しません。

ストレステストと実際の再現 — 本稿でいちばん重要な区別

Debianには再現性を見るシステムが2つあります。そしてこの2つを混同すると、数字を完全に読み違えます。

tests.reproducible-builds.org は2015年から動いている古いほうです。Paul Gevers氏の表現でいえば、これはストレステストです — 同じパッケージをわざと異なる条件で2回ビルドします。スライドがこの方式を呼ぶ名前は変動性テスト(variance testing)で、目的は「パッケージの再現を妨げうる要因」を狩ることです。わざと変数を揺さぶって弱点を見つけ出します。

reproduce.debian.net は2024年に始まった新しいほうで、今回ゲートに接続されたのはこちらです。目的は正反対です。スライドの文をそのまま引くと、

The goal of reproduce.debian.net is to replicate the same build process that is used by Debian during package publication -- not to seek out additional sources of variance.

追加的な変数を探しに行くことはしません。Debianがパッケージを配布する際に使った、まさにそのビルド過程をそのまま複製しようとします。

Paul Gevers氏が5月30日の続報メールでこの違いを改めて強調した箇所が本稿の核心なので、そのまま引用します。

there is a very clear difference in the way reproducibility is tested on https://tests.reproducible-builds.org/ vs https://reproduce.debian.net/. While the former is a stress test, the latter tries, with the info in the .buildinfo file, to reproduce what we ship. It's the latter case what some people call "easy", but it's also what matters to our users: can the binaries they use be reproduced.

後者を「簡単だ」と呼ぶ人がいることを、彼はまず認めます。そしてすぐに反論します — 簡単であろうがなかろうが、ユーザーにとって重要なのはそちらだ、と。ユーザーが実際に使うそのバイナリが再現できるかどうか。

これはエンジニアリング判断として噛み締める価値があります。ゲートをストレステストに接続していたら、通過率ははるかに低くなり、ポリシーは何年も先送りされていたでしょう。代わりに「簡単な」ほうに接続することで、今すぐ有効化できました。完璧な基準を待つのではなく、今すぐ強制できる基準を選んだということであり、LWN記事のコメントで出た指摘もまさにこの点です — この要求の範囲は「Debianのビルド環境インスタンス内でビルドすること」に限定されており、再現性は是か非かの二分法ではなくスペクトラムだ、という指摘です。

reproduce.debian.netはどう動くか

構造自体は正直でシンプルです。rebuilderdインスタンスです。

rebuilderdはkpcyrd氏がRustで書いたツールで、2019年のMarrakechサミットで開発が始まり、Arch、Fedora、Debian、Tailsの再ビルドをサポートします。Arch用のインスタンスが5個ほど、Fedora用が1個、Debian用が5〜6個存在します。つまりDebian専用に新しく作られたものではなく、すでに他のディストリビューションで動いていたものをそのまま持ってきたということです。

reproduce.debian.netがやっていることはこうです。

Attempts to bit-for-bit identically rebuild each Debian binary package found in the distribution archive, using the .buildinfo file produced when the buildd originally built the package. For each distributed package, rebuilderd calls debrebuild that calls debootsnap, mmdebstrap and finally sbuild to build that package within a user namespace.

ここで軸になるのが .buildinfo ファイルです。Debianのビルドデーモン(buildd)がパッケージをビルドする際、そのビルド環境を記録したcontrolファイルを一緒に残します。どのパッケージがどのバージョンでインストールされていたかがここに書かれます。再ビルドはこのファイルを読んでその環境を蘇らせたうえで、その中で再びビルドし、結果を配布されたバイナリとビット単位で比較します。

ftp.debian.org が配布中のバイナリパッケージ
        │
        │   buildd が元のビルド時に残した .buildinfo
        │   (= そのときのビルド環境の記録)
        ▼
  rebuilderd
        └─► debrebuild ─► debootsnap ─► mmdebstrap ─► sbuild
                                                        └─ user namespace 内で再ビルド
        │
        ▼
   配布されたバイナリとビット単位で比較
        │
        ├─► 一致  ─► good
        └─► 不一致 ─► bad  (diffoscopeで何が違うか確認)

余談ですが面白い事実がひとつ。スライドの中でHolger氏は、.buildinfoは事実上SBOMだと指摘しています — 最近みんなが話すSoftware Bill of Materialsは、Debianでは2014年に設計された.buildinfoファイルとだいたい同じものだ、というわけです。

カバレッジは2026年5月9日の発表時点でこうです。trixie以降、mainとnon-free-firmwareの全体をカバーしており、対象スイートはexperimental、unstable、forky、trixie、trixie-security、trixie-updates、trixie-proposed-updates、trixie-backportsです。アーキテクチャはs390xとloong64を除く全部(trixieにはarmelも含む)。発表時点でアーキテクチャごとにインスタンスを個別に立てて、8個を運用していました。

loong64が抜けているのは偶然ではありません。同じ5月10日のメールの別セクションによると、loong64はその2週間前にアーカイブに追加されたばかりのアーキテクチャで、そのためあらゆるパッケージを全アーキテクチャで再ビルドする必要があり、CIキューが詰まっているので辛抱強く待ってほしいという案内が付いていました。新しいアーキテクチャが入ると、再現性インフラもそれに追いつかなければならない、ということです。

ゲート — britneyが実際に止めるもの

Debianでは、パッケージがunstableにアップロードされた後、一定の条件を満たすとtestingへ「移行」(migration)します。この移行を決めるソフトウェアがbritneyであり、次の安定版リリースはtestingが凍結されて作られます。つまりtesting移行を止めるということは、次のリリースに入れないということです。

発表スライドの表現はこうです。

britney now finally has been configured to not let (most) unreproducible packages migrate to testing!

ここで注目すべき単語は括弧内の most です。全部ではありません。スライド自身が挙げる実際のルールはこうです。

移行が止まる場合:

再現しない新規(NEW)パッケージ
回帰 — 以前は再現していたパッケージが再現しなくなった場合

そしてすぐに付く注釈:

要求すれば解除できる(can be unblocked on request)
allowlistが可能(現在の例:udeb)
特定アーキテクチャの結果は無視することもできる

リリースチームの立場は、スライドにこうまとめられています。

すべてのパッケージは再現可能であるべきだ
しかし今は新規の再現不可パッケージと回帰だけを止める
再現不可能なパッケージはまだRCバグとして扱われておらず、まだ自動削除もされない

最後の一行が、このポリシーの実際の強度を物語っています。Debianにおいて RC(release-critical)バグはリリースを止める等級であり、長く放置されるとパッケージはtestingから自動的に外れます。再現不可能はまだその等級ではありません。つまり、すでに入り込んでいる再現不可能なパッケージ群は、事実上の祖父条項として残ります。

そして発表者本人がforkyについてこう釘を刺します。

for forky we will be rather liberal with accepting unreproducible packages.

forkyでは再現不可能なパッケージを受け入れることにかなり寛容にいく、ということです。次のリリースであるdukeについては、スライドは問いの形で開いたままにしています — mainで再現不可能なパッケージ0を目標に掲げるかどうか。疑問符が付いており、決まってはいません。

Paul Gevers氏が5月30日に送った続報メールも同じ方向です。元の発表で言い忘れたとして、こう付け加えています。

I forgot to mention that while we of course want all packages in testing to reproduce, we recognize there will be exceptions (which numbers hopefully will reduce over time). If you think your package needs an exception, please file a bug against the release.debian.org pseudo package (option 4 "other" in reportbug for now) and explain why you're not able to fix the issue.

例外は存在するはずで、必要ならrelease.debian.org疑似パッケージにバグを立てて、なぜ直せないのかを説明してほしい、ということです。例外申請の窓口が公式に開かれています。

まとめると、このゲートは ラチェット です。閾値を一段上げたら、二度と下がらないようにする装置。「これから新しく入るものは再現しなければならず、すでに再現していたものは壊れてはならない。」既存の負債を掃除する装置ではなく、負債がこれ以上増えないようにする装置です。これが物足りない話に聞こえるなら、逆に考えてみてください — 数万個のパッケージを抱えるプロジェクトで、回帰を止める仕組みなしに再現率を上げようとするのは、底の抜けた甕に水を注ぐようなものです。

Holger氏のスライドには、この政治的な性格がかなり率直に書かれています。

100% reproducible is a political decision and nothing technical. We need to change debian-policy!

100%再現可能は技術的な問題ではなく、政治的な決定だということです。debian-policyは2017年以来、パッケージは再現可能にビルドされる「べきだ」("should")としか書いておらず、これを「しなければならない」("must")に変えるのはポリシー改定手続きです。だからリリースチームは、ポリシーより先に移行ゲートで強制する道を選びました。スライドの表現では「In practice the release team will enforce this before it becomes official Debian policy.」

数字 — 2026年5月9日時点

以下はすべて、Holger Levsen氏のMiniDebConf Hamburg 2026発表(2026年5月9日)のスライドに書かれたreproduce.debian.netの数値です。発表時点のスナップショットであり、今は変わっている可能性があります。

forky(次の安定版リリースになるスイート):

アーキテクチャ	good	bad sources
arch:all	98.3%	419
amd64	97.2%	512
arm64	97.7%	408
armhf	97.1%	507
i386	97.0%	523
ppc64el	91.1%	531
riscv64	91.6%	338

比較用に他のスイート:

スイート / アーキテクチャ	good	bad sources
unstable arch:all	98.0%	515
unstable amd64	97.6%	469
trixie arch:all	91.7%	2001
trixie amd64	95.6%	803
trixie-backports arch:all	79.5%	53
trixie-backports amd64	83.5%	32
trixie-security arch:all	82.9%	17

読み取れることがいくつかあります。

主力アーキテクチャとそれ以外の格差。 amd64は97.2%なのにppc64elは91.1%です。6.1ポイントの差です。再現性はアーキテクチャごとに個別に達成しなければならない性質であり、関心と人手が集まるアーキテクチャが先に上がります。ゲートが「特定アーキテクチャの結果は無視することもできる」という注釈を付けている理由が、この表に表れています。

backportsが低い。 trixie-backportsは79.5% / 83.5%と目立って低い値です。安定版リリースに新しいバージョンを載せる通路であるため、ビルド環境がずれやすいことの表れと読めます。

ストレステストと実際の再現が、ほぼ同じ値に収束した。 スライドには「The diff between theory and practice today?」という見出しで、2つの数字が並べて置かれています — CI(ストレステスト)で96.6%、amd64.reproduce.debian.net(実際の再現)で96.54%。先ほど後者を「簡単な」ほうと呼びましたが、実際には両者の差はわずか0.06ポイントです。もちろん2つのシステムは対象スイートと集計方法が異なるため厳密な同一比較ではありませんが、「簡単なテストだから数字が水増しされているのでは」という疑いへの反証としては十分に興味深いものです。スライドはここに「we've only been doing this for 10 months & the freeze...」という注釈を付けています。

個人のシステムで直接確認できる。 debian-repro-statusパッケージをインストールすると、今自分のシステムに入っているパッケージのうち何個が再現しないかが分かります。発表者本人のシステムの出力がスライドに載っています。

$ sudo apt install debian-repro-status
$ debian-repro-status
INFO debian-repro-status > 60/2268 packages are not reproducible.
INFO debian-repro-status > Your system is 97.35% reproducible.

このツールが私には最も印象的でした。再現性がウェブサイトのダッシュボードの数字ではなく、自分のノートPCで一行確認できる性質になった、ということですから。

何が再現を壊すのか

スライドが理由を並べる書き方自体が、ひとつの冗談になっています。

Common reasons for unreproducibilities:

  timestamps, timestamps, timestamps
  timestamps, timestamps, timestamps
  build paths, build paths
  all the rest

  (and somewhere in there there might be backdoors...)

タイムスタンプが6回、ビルドパスが2回、残り全部が1回。この12年間、このプロジェクトが何と戦ってきたかの要約です。そして最後の一行が、なぜこの退屈な戦いをするのかを教えてくれます — そのどこかにバックドアが潜んでいるかもしれない、と。

タイムスタンプに対する標準的な解法が SOURCE_DATE_EPOCH です。仕様はこうです。

SOURCE_DATE_EPOCH specifies the last modification of something, usually the source code, measured in the number seconds since the Unix epoch, ie. January 1st 1970, 00:00:00 UTC.

ディストリビューションがこの環境変数を中央で設定すれば、ビルドツール群は現在時刻の代わりにこの値を刻みます。ただしReproducible Builds文書自身が付ける注釈も一緒に読む必要があります — 「Setting the system clock is not enough for reliable reproducible builds.」時計を固定するだけでは足りません。SOURCE_DATE_EPOCHが扱うのはタイムスタンプの問題だけであり、非決定的なビルド過程や不安定な依存関係から来る変動には手が届きません。

規模感のために: 2026年5月8日時点のCI統計によると、再現性関連のバグ4,347件が修正され(大半は上流に反映)、262件のパッチが待機中です。12年間、毎日数件ずつ地道に押し進めてきた結果が今の97%です。魔法はありませんでした。

そして、まだできていないものの一覧が謙虚にさせてくれます。スライドは、最も人気のあるパッケージ1,337個のうち再現しないソースパッケージが22個あるとして、名前を挙げています — ffmpeg、vlc、bluez、nss、grub2、graphviz、pipewire、qtwebengine、bind9など。もっと痛いのは、build-essentialの依存関係にある5,500個のうち96個が再現しないという一覧です。そこには rustc、python3.12、python3.13、ghc、gcc-13-cross、qemu、valgrind、chromium が入っています。

コンパイラとインタプリタ自身が、まだ再現していません。これがなぜ難しいのかについての、最も凝縮された説明です。

だからといって進展がないわけでもありません。2026年6月の報告書によると、debian-installerのアップロードが初めて再現に成功し、debian:sidコンテナは100%再現可能になりました。diffoscopeはその一か月だけで319、320、321、322、323の5つのバージョンが出ました。

正直な限界

好意的に読みたい気持ちを脇に置いて整理すると、こうなります。

見出しがポリシーより強い。 「Debian must ship reproducible packages」は強い文ですが、有効化された仕組みは新規パッケージと回帰だけを止めます。既存の再現不可能なパッケージはそのままで、RCバグでもなく、自動削除もありません。forkyでは寛容にいくと発表者が明言しています。

逃げ道が複数あります。 要求時のunblock、allowlist(現在はudeb)、アーキテクチャ別結果の無視、release.debian.orgへの例外申請。それぞれは合理的な仕組みですが、まとめて見ると、ゲートの実効的な強度はリリースチームの裁量にかかっています。

検査の範囲が狭い。 reproduce.debian.netはDebianのビルド環境をそのまま複製して比較します。異なるビルドパス、異なるカーネル、異なるロケールでも再現するかどうかは、このゲートは問いません。LWNのコメントが指摘する通り「再現可能」は二分法ではなくスペクトラムであり、このゲートはそのスペクトラムの一点を選んだにすぎません。その一点がユーザーにとって最も重要な点だというPaul Gevers氏の反論も妥当ですが、2つの命題は同時に真です。

ツールがまだ粗い。 Paul Gevers氏本人が続報メールで認めた箇所です — NT_GNU_BUILD_IDの違いで再現しないパッケージの場合、現在のdiffoscopeログは理想的ではないと。実際の差分は切り落とされ、dbgsymパッケージにしか現れないはずですが、それは現在自動比較の対象になっていないというのです。つまりメンテナが「なぜだめなのか」を見ようとしても、ログが答えをくれない場合があります。

信頼が一箇所に集中している。 これは発表者自身が提起した問題です。スライドにはこう書かれています — 「Because do you really want to put all your trust in me???」今はreproduce.debian.netという特定のインスタンスの判定を信頼する構造です。再現可能なビルドの本来の趣旨は、複数の独立した当事者がそれぞれ検証することですが、検証者が1つだけならその趣旨は半分しか実現しません。だからスライドはrebuilderdインスタンスをもっと立ててほしいと要請し、今後の課題として透明性ログを使った信頼の分散と比較を挙げています。

では、あなたのCIは何を持ち帰れるか

この事例から一般化できることがいくつかあります。ただしDebianは数万個のパッケージと12年分の人手を積み上げてきたディストリビューションであり、あなたのサービスはそうではありません。そのまま移してはいけません。

持ち帰れるもの1 — ラチェットは目標より強い。 Debianが実際に有効化したのは「全部再現させろ」ではなく「新しい負債を止め、回帰を止めろ」でした。これは再現性だけの話ではありません。テストカバレッジであれ型カバレッジであれリント警告であれ、既存の負債を一気に掃除しようとする試みはたいてい失敗し、回帰を止めるゲートはたいてい成功します。既存の違反はallowlistに入れて凍結し、新規と回帰だけを止めてください。Debianがudebをallowlistに入れたのと同じやり方です。

持ち帰れるもの2 — ビルド環境を記録するファイル。 .buildinfoの発想はシンプルです。ビルド時に何がどのバージョンで存在していたかを、成果物の隣に残す。これがあれば後でその環境を蘇らせられ、なければ再現は始まりすらしません。最近SBOMと呼ばれているものとだいたい同じもので、Debianはこれを2014年に作りました。lockfileをコミットし、ベースイメージをタグではなくダイジェストで固定し、ツールチェーンのバージョンを記録することが、同じ系列の実践です。

持ち帰れるもの3 — SOURCE_DATE_EPOCH。 タイムスタンプが最も多い犯人だというのが、12年分のデータの結論です。ツールがこの環境変数をサポートしているなら、有効化するコストはほとんどありません。

持ち帰れるもの4 — 再現検査は別ジョブに。 rebuilderdがビルドパイプラインの中にあるのではなく、配布された成果物を外から作り直してみる、という構造が重要です。再現検査をメインCIにインラインで組み込むと、ビルド時間が2倍になり、結局オフにされます。デプロイ後に非同期で再ビルドし比較する別パイプラインが現実的です。

やってはいけないこと。 正直に言うと、ほとんどのチームにとってビット単位の再現可能性は過剰です。

配布成果物を他者が検証する必要がないなら — 社内サービスをコンテナで動かし、イメージダイジェストを固定して使っているなら — 再現可能性が与える追加の保証は大きくありません。すでに「そのダイジェストがそのダイジェストである」ことは確実だからです。
再現可能性が価値を持つのは、配布先が多数の信頼できない第三者であり、彼らがソースとバイナリの対応を独立に検証する必要がある場合です。ディストリビューション、ブラウザ、ウォレット、メッセンジャー、ファームウェア。Debianが12年をかけた理由がこれです。
その中間にいるなら、全部を再現対象にするのではなく、核となる成果物ひとつだけを再現対象にするほうが良いでしょう。Debianもツリー全体を一度にはやりませんでした。
そして再現可能性をセキュリティ対策として売るのは不誠実です。先の一文を再び引用すれば、再現可能にビルドされた脆弱なソフトウェアは、それでも脆弱なソフトウェアです。

おわりに

2026年5月9日にDebianで起きたことは、こう要約できます。britneyがreproduce.debian.netの判定を読み始め、再現しない新規パッケージと再現性が回帰したパッケージのtesting移行を止め始めました。発表時点でforkyのamd64再現率は97.2%で、再現しないソースパッケージが512個残っています。

見出しが語るよりも狭い措置です。例外の窓口が開いており、allowlistがあり、アーキテクチャ別に無視でき、既存の再現不可能なパッケージはそのまま残り、forkyでは寛容にいくと明言されています。検査の範囲もDebianのビルド環境を複製することに限定されます。

それでもこれが意味を持つのは、12年間「should」だったものが、初めて実際に何かを止め始めたからです。ポリシー文書を書き換えるにはプロジェクト全体の合意手続きが必要ですが、ゲートを有効化するにはbritneyの設定を変えるだけで済みます。元の発表の表現を借りれば、コードとしては小さな一歩です。リリースチームはその小さいほうを先にやり、スライドの表現通り「ポリシーになる前に実務で先に強制する」道を選びました。

ここで学ぶべきは、再現性そのものよりもその方法論かもしれません。目標は100%だと宣言しつつ、有効化するのはラチェット一段だけ。完璧な基準を待つのではなく、今強制できる基準を選び、それが「簡単な」基準だという批判を正面から受け止めたうえで、それでもユーザーにとって重要なのはこちらだと答えること。dukeで0を目標にするかどうかは、まだ疑問符のまま残っています。