Debian 14 'Forky'、再現可能ビルドを必須とする初のメジャーLinuxディストリビューションに

2026年5月10日、Debian リリースチームは発表しました：今後、Debian の移行ソフトウェアはビット単位で再現できないパッケージ（または再現性が低下するパッケージ）が testing ブランチに入るのをブロックします。これは、2027年にリリース予定の Debian 14 “Forky” が、すべてのパッケージに再現可能ビルドを必須とする初のメジャー汎用Linuxディストリビューションになることを意味します。

同じ発表で、LoongArch64（Loong64）が正式にDebianアーカイブに追加されたことも確認されました。

これは単なるポリシー変更ではありません。最も古く、最も影響力のあるLinuxディストリビューションの一つが、ソフトウェアサプライチェーンの完全性を保証する方法における構造的な変化です。技術的、経済的、地政学的な意味を詳しく見ていきましょう。

なぜ今なのか？XZバックドアが分水嶺に

この重要性を理解するには、XZ Utils バックドア（CVE-2024-3094）を理解する必要があります。セキュリティ研究者のAlex Stamos氏はこれを「これまでにソフトウェア製品に仕掛けられた中で最も広範囲で効果的なバックドア」と呼びました。

XZ Utils プロジェクトのロゴは、バックドア実行者 "Jia Tan" によって寄贈されました。出典: Wikipedia

2024年、攻撃者は2年以上の時間をかけて、xz/liblzmaプロジェクトのメンテナー信頼チェーンにソーシャルエンジニアリングで侵入しました——圧力キャンペーン、ソックパペット、偽の緊急感——そして主要なLinuxディストリビューションすべてが出荷する圧縮ライブラリバイナリにバックドアを仕込みました。特定のEd448秘密鍵を持つ攻撃者は、SSH経由でrootとしてリモートコード実行が可能でした。CVSSスコアは10.0——最大の深刻度です。広範囲に展開される前に発見されたのは、MicrosoftのエンジニアAndres Freund氏がSSHログインが通常より約500ms遅いことに気づいたからに他なりません。

Veritasiumがこの攻撃に関する優れたドキュメンタリーを制作しています。

重要な教訓：ソースからバイナリを再現できなければ、それが実際に何をするのかを知ることはできない。 XZバックドアの悪意あるコードはリリースtarballにのみ存在し、gitリポジトリにはありませんでした。再現可能ビルドのセットアップがあれば、この不一致を即座にフラグできたでしょう：tarballとgitチェックアウトからは異なるバイナリが生成され、ビルドは拒否されていたはずです。

これが、Debianの発表が対応している上流の脅威です。

執行メカニズム：実際に何が変わったのか

Reproducible Builds プロジェクト（reproducible-builds.org）は2014年から存在しています。Debianは中核的な参加者であり、プロジェクトのCI基盤は主にDebianハードウェア上で動作しています。この発表の前から、Debianのソースパッケージの95%以上がすでに再現可能でした。5月10日に変わったのは、移行ツールチェーンへのハードゲートの追加です。

Debianのリリースフローは次のように機能します：

メンテナーが unstable（Sid）にアップロード
移行遅延（通常5〜10日）後、testing へのプロモーションが検討される
移行ソフトウェアが自動チェックを実行：依存関係解決、アーキテクチャサポート、バグ追跡ステータス、そして再現可能性

5月10日以前は、再現可能性のチェックは助言的なものでした——ダッシュボード上のメモに過ぎませんでした。現在はブロッキングチェックです。パッケージ foo のバージョン2.0-1が再現不可能な場合、またはバージョン2.0-1によって foo が再現可能から再現不可能に変わった場合、移行ツールはプロモーションを拒否します。

これは .buildinfo ファイルによって強制されます——これらは完全なビルド環境を記録する成果物です：すべての依存関係のバージョン、すべてのコンパイラフラグ、ビルドパス、カーネルバージョン、ロケール設定。diffoscope（2つのバイナリを深く比較し、すべてのバイトレベルの差異を報告するツール）と組み合わせることで、システムはパッケージのソースコードが独立したビルドで同一の出力を生成するかどうかを判断できます。

現実的な結果：Debianメンテナーは、パッケージが安定版リリースパイプラインを通じてユーザーに届く前に、再現可能性の問題を修正しなければなりません。パッチやバグクローズで回避することはできません——移行ゲートが阻止します。

より深い意味：これが実際に意味すること

1. 信頼モデルのシフト：「私たちを信頼して」から「私たちを検証して」へ

すべてのバイナリパッケージ配布システムは信頼モデルに基づいて動作します。この変更以前の信頼モデルは次のようなものでした：「Debianのビルドデーモンは安全です。私たちが出荷するバイナリが表示するソースと一致することを信頼してください。」

この変更後、モデルは次のように変わります：「誰でも独立して、私たちが出荷するものがソースと一致することを検証できます。一致しない場合、システムは出荷を拒否します。」

これは重要な違いです。つまり、Debianのビルドインフラが侵害された場合——例えば、攻撃者がビルドデーモンクラスターにアクセスし、コンパイル後にバイナリを改ざんした場合——再ビルドを実行する誰でも検出できるということです。攻撃者は独立した再ビルド検証すべてを同時に侵害する必要があり、これは本質的により困難な目標です。

2. 上流プロジェクトへの経済的压力

見過ごされがちな結果：再現可能ビルドをサポートしない上流プロジェクトは、Debianから締め出されることになります。 上流プロジェクトのビルドシステムがタイムスタンプを埋め込み、ファイルシステムのreaddir順序に依存し、またはコンパイル中にランダムな識別子を生成する場合、Debianパッケージメンテナーはそれらの問題にパッチを当てるか、例外を求めて主張する責任を負います。

「再現可能ビルドの十戒」は、非決定性の最も一般的な原因を文書化しています：

タイムスタンプ：ビルド日付がバイナリに埋め込まれる（SOURCE_DATE_EPOCH で修正）
ファイルシステム順序：readdir() が任意の順序でファイルを返す（決定論的ソートまたは ar アーカイブで修正）
ビルドパス：/home/user/build/foo と /build/foo で異なる出力（-ffile-prefix-map または BUILD_PATH_PREFIX_MAP で修正）
ロケール：sort が en_US.UTF-8 と zh_CN.UTF-8 で異なる順序を生成（LANG=C の設定で修正）
ランダム性：一時ファイル名がUUIDを生成（決定論的にする必要あり）
タイムゾーン：出力がタイムゾーンによって変化（UTCに固定する必要あり）

それぞれ解決可能ですが、それぞれに作業が必要です。結果として、Debianはオープンソースエコシステム全体に下流からの経済的压力をかけ、決定論的ビルドプラクティスの採用を促しています。これが今回の発表の最も重要なエコシステムレベルの影響かもしれません。

3. 下流への影響：Ubuntu、Kaliなど

Debianは120以上の派生ディストリビューションの上流であり、Ubuntu、Kali Linux、Linux Mint、MX Linux、Raspberry Pi OS、Tails などが含まれます。Debianが testing ブランチに再現可能ビルドを義務付けると、testing を追跡するすべての派生ディストリビューションがこの保証を継承します。

Ubuntuは特に注目に値します。XZインシデントの際、CanonicalはUbuntu 24.04 LTSのベータ版を延期し、アーカイブ全体の再構築を実行しました——これは非常にコストのかかる操作です。再現可能ビルドパイプラインがあれば、検証コストは劇的に削減できたでしょう：30000以上のパッケージすべてを再構築する代わりに、ビルド成果物が期待されるハッシュと一致しないパッケージのみを選択的に再構築すればよかったのです。

4. 他のディストリビューションとの比較

最も近い既存の類似例は NixOS で、再現可能ビルドを中核的な設計目標としてきました。Nixのコンテンツアドレス型ストアは本質的に再現可能性検証をサポートしています。ただし、NixOSは普遍的な再現可能性を義務付けたことはありません——Nixエコシステムでも決定論的にビルドされるパッケージの割合は高いですが（90%超）、Debianが導入したようなハードゲーティングはありません。

Guix はさらに進んでおり——ブートストラッパブルビルドにより、信頼済みコンピューティングベースを手作業で監査可能な小さなバイナリシードにまで縮小することを目指しています。

Fedora は再現可能ビルドに取り組んでいますが、ハードポリシーの義務化は発表していません。Arch Linux は現在、パッケージングツールチェーンに再現可能ビルドのインフラを持っていません。

Debianの動きが注目に値するのは、再現可能性をハード要件にした最初のメインストリーム汎用ディストリビューションだからです——機能ではなく、ベストプラクティスではなく、ゲートです。

5. LoongArch64：地政学的な側面

LoongArch64（Loong64）がDebianアーカイブに入るという同時発表は、この文脈で注目に値します。LoongArchはLoongson Technologyが開発した中国のCPU ISAであり、x86やARMの代替として設計されています。Loongsonはより広範なソフトウェアエコシステムのサポートを推進しており、DebianのLoongArchポートは重要なマイルストーンです。

タイミングは興味深いものです。異なるサイバーセキュリティ上の利害を持つ国からの新しいアーキテクチャを追加すると同時に再現可能ビルドを義務付けることで、Debianは強力な信頼フレームワークを構築します：誰でもLoongArchバイナリがソースと一致することを検証でき、地政学的に敏感な文脈でビルドインフラを信頼する必要性を減らします。

欠けているもの：難しい問題は残る

その野心にもかかわらず、このポリシーはすべてのサプライチェーン問題を解決するわけではありません：

ブートストラップ問題。 Debianをビルドするために使用される最初のコンパイラ自体が信頼されなければなりません。再現可能ビルドはコンパイラが自己無矛盾であることを検証できますが、Ken ThompsonスタイルのTrusting Trust攻撃の不在を証明することはできません——改ざんされたコンパイラがコンパイルするすべてのプログラム（将来の自身のバージョンを含む）にバックドアを挿入するものです。Guixのブートストラッパブルビルドの取り組みはこれに対処していますが、Debianはまだ採用していません。

再現可能性 ≠ セキュリティ。 再現可能なバイナリでも脆弱性を含む可能性があります。再現可能性はバイナリがソースと一致することを保証します——ソースにバグがないことを保証するわけではありません。2024年に数百万台のサーバーに影響を与えたOpenSSHの脆弱性CVE-2024-6387（regreSSHion）は、再現可能ビルドでは発見できませんでした。

ハードウェア依存ビルド。 一部のパッケージは、CPUアーキテクチャの機能や利用可能な命令セットによって異なる出力を生成します。異なるビルドハードウェア間での真の再現可能性は依然として課題です。

まとめ

Debian 14 “Forky” は単なるリリースではありません——再現可能ビルドが専門家の関心事からメインストリームの要件へと移行した瞬間を示しています。XZバックドアは脅威モデルが現実であることを実証し、オープンソースエコシステムのボランティア駆動の信頼モデルが脆弱であることを示しました。Debianの答えはより多くの信頼を追加することではなく、コードによって信頼を検証可能にすることです。

移行ゲートはすでに有効です。Reproducible Buildsプロジェクトの10年にわたる取り組みは執行段階に達しました。すべてのパッケージメンテナー、すべての上流プロジェクト、そしてすべての派生ディストリビューションがその結果を感じることになるでしょう。

「私たちを信頼してください、私たちがビルドしています」の時代は終わりつつあります。「私たちを検証してください、方法はここにあります」の時代がDebian 14から始まります。