言語パッケージマネージャーにおける再現可能なビルド

レジストリからパッケージをダウンロードすると、そのパッケージは特定の Git コミットからビルドされたものだとレジストリは言いますが、受け取った tarball や wheel、あるいは crate は、誰かが自分のマシンでビルドしてアップロードした不透明なアーティファクトです。再現可能なビルド（Reproducible Builds）を使えば、自分でソースコードから再ビルドして比較することで検証でき、同じバイト列が得られれば、そのアーティファクトは主張通りのものであると確認できます。これを機能させるには、ビルド環境とアーティファクトの出自（プロベナンス）の両方を制御する必要があり、歴史的に見てほとんどの言語パッケージマネージャーはどちらも制御していませんでした。 再現可能なビルドプロジェクトは 2013 年からこの取り組みを開始しており、その際 Lunar（Jérémy Bobbio）が DebConf13 でセッションを組織し、Debian のビルドツールチェーンの修正に取りかかりました。Snowden による情報開示によりソフトウェアの信頼性が緊急の課題となり、Bitcoin の Gitian ビルダーが単一プロジェクトに対してこのアプローチが実現可能であることを示しており、Tor プロジェクトも Tor Browser の決定論的ビルド（deterministic builds）の生産を開始していました。Lunar は同じ考え方をオペレーティングシステム全体に適用したかったのです。 2013 年 9 月の Debian パッケージにおける最初の大量再ビルドでは、24% が再現可能であることが判明し、dpkg および一般的なビルドヘルパーの最も簡単な課題を修正した後の 2014 年 1 月には、その割合は 67% に跳ね上がりました。現在、Debian のテストインフラストラクチャでは、trixie のパッケージの約 96% が制御された条件下で再現可能にビルドされていることが示されており、reproduce.debian.net は ftp.debian.org が配布する実際のバイナリを再ビルドすることで、クリーンルームでのテストビルドよりも厳しいテストを実行しています。 このプロジェクトは、Arch Linux、NixOS、GNU Guix、FreeBSD など他の多くのディストリビューションが数年のうちに参画したことで、クロスディストリビューション型の取り組みへと成長しました。サミットは 2015 年以降ほぼ毎年開催されており、最も最近のものでは 2025 年 10 月にウィーンで開催されました。2017 年から 2019 年に Debian プロジェクトリーダーを務めた Chris Lamb は、このプロジェクトに関する IEEE Software の論文を共著し、それが 2022 年の最優秀論文賞を受賞しました。Lunar は 2024 年 11 月に逝去しました。2015 年から継続的に発表されているプロジェクトの週報は、関与する作業の規模感を示しています：各報告書には、タイムスタンプ、ファイル順序、パス埋め込み、ロケール依存性といった問題を修正するためのパッチが、一度に一つのアップストリームパッケージ宛てに送信されたリストが記載されており、年間数百のパッケージに及んでいます。24% から 96% への達成は、単一のアーキテクチャ的修正によるものではなく、Debian アーカイブ全体にわたるこの種の清掃的なパッチ適用を十年間継続した結果です。 検証の仕組み 異なる環境で同じソースコードを二度ビルドし、出力を比較します。もしバイト列が一致すれば、ソースと配布物の間で誰かがアーティファクトを改ざんしていないことを意味します。実際にはこれにはビルド環境に関するすべての情報を記録する必要があり、Debian では .buildinfo ファイルを用いてそれを行っています。 ハッシュ値が一致しない場合、その理由を見つける手段として diffoscope が用いられます（元々は Lunar によって debbindiff として開発されました）。 このプロジェクトはまた、strip-nondeterminism も維持管理しています。 ビルドが非再現的になる要因 Benedetti らは、reprotest を用いて 6 つのエコシステムそれぞれから 4,000 パッケージずつテストしました。 3 つの失敗したエコシステムすべてに共通する主な原因は、パッケージアーカイブに埋め込まれたタイムスタンプであり、これは RubyGems の失敗の 97.1%、Maven の失敗の 92.4%、PyPI の失敗の 87.7% を引き起こしていました。標準的な解決策は SOURCE_DATE_EPOCH です。 この問題のほとんどは、パッケージごとの作業ではなくインフラストラクチャの変更によって修正可能であることがわかりました。SOURCE_DATE_EPOCH を設定するだけで十分です。 os.path.expanduser ファイル順序も同様の問題を発生させます。readdir() 関数の結果がホストシステムやユーザー環境に依存するためです。例えば、/home/alice/project と /home/bob/project のようなパスの違いが問題となります。 2023 年 8 月の Go 1.21 以降、Russ Cox 氏のチームがマップの反復順序、埋め込まれたソースパス、アーカイブ内のファイルメタデータ、ARM フローティングポイントモードのデフォルトなど、10 の異なる非決定性要因を排除した結果、ホスト OS、アーキテクチャ、ビルド時間に関係なく、ビット単位で完全に同一の出力が生成されるようになりました。 Go は go.dev/rebuild 上で gorebuild を使用して毎晩検証を実行しています。 Maven の公式ガイドには手順が記載されています：project.build.outputTimestamp を設定し、mvn clean verify artifact:compare コマンドを実行します。 ただし、タイムスタンプが機能するのはチェーン内のすべてのプラグインがこれを尊重する場合に限られます。多くのサードパーティ製プラグインはこれに対応していません。異なる JDK バージョンではバイトコードが異なり、ZIP エントリの順序も実装によって異なります。また、Maven ビルドは数十のプラグインから構成されており、それぞれが独自の潜在的な非決定性をもたらします。研究者たちは Java ビルドの再現不可能性の 6 つの根本原因を正規化するために Chains-Rebuild を構築しました。これは、単一のビルドシステム内でどれほど多くの別々のことが失敗し得るかを示す指標となっています。 Rust の RFC 3127 は、trim-paths（パスのトリミング）を導入しました。 /home/alice/.cargo/registry/src/crates.io-abc123/serde-1.0.200/src/lib.rs serde-1.0.200/src/lib.rs 手動マクロおよびビルドスクリプト（build.rs） Benedetti 氏らの研究では、PyPI パッケージの約 12.2% がそのまま再現可能であることが判明しましたが、その違いはビルドバックエンドに起因していました。flit を使用するパッケージは…… PyPI はまた、2024 年 10 月にリリースされた PEP 740（注：デジタル証明書の付与に関する提案）を通じて、他のレジストリよりも一歩先を行く取り組みを進めています。これにより、パッケージと共にアップロードされる Sigstore 署名付きのデジタルアテステーション（証明）がサポートされます。これにより、各アーティファクトを生成した OIDC 識別子と紐付けられ、信頼できる公開機能と組み合わせることで、PyPI は特定の CI ワークフロー内で特定のコミットからパッケージがビルドされたことを記録し、アーティファクトとソースコードを暗号学的に結びつける署名を付与できます。 RubyGems 3.6.7 では、デフォルトで SOURCE_DATE_EPOCH（ビルド日時の統一環境変数）を設定することで、gem のビルドプロセスの再現性を向上させました。 npm レジストリは、ソースとの関連性もビルドの出自証明もない任意の tarball を受け入れており、パッケージを独立して再構築して公開されたものと比較する方法がありません。package-lock.json（依存関係の固定ファイル） Homebrew は、GitHub Actions でビルドされ、GitHub リリースアーティファクトとしてホストされている「bottles」と呼ばれる事前ビルド済みバイナリを配布しています。このプロジェクトには、formula 作者が利用可能なメカニズムを文書化した再現可能ビルドのページがあり、SOURCE_DATE_EPOCH（ビルド日時の統一環境変数）や @@HOMEBREW_PREFIX@@（Homebrew のインストール先パス）、Utils::Gzip.compress（gzip 圧縮ユーティリティ関数）などが紹介されています。 2024 年 5 月の Homebrew 4.3.0 以降、すべてのボトルには Sigstore に基づくアテステーションが付帯しており、それを構築した特定の GitHub Actions ワークフローとリンクされています。これは SLSA Build Level 2 の要件を満たすものです。ユーザーは HOMEBREW_VERIFY_ATTESTATIONS=1 を設定することで、アテステーションを検証できます。 信頼できる公開（Trusted publishing） 従来、メンテナは API トークンで認証し、ローカルマシンでビルドしてアップロードしていました。信頼できる公開ではこれを CI からの OIDC トークンに置き換え、レジストリがパッケージを単に適切な権限を持つ誰かがアップロードしたのではなく、特定のレポジトリ内の特定の GitHub Actions ワークフローによって構築されたものであることを確認できるようにします。 PyPI は 2023 年 4 月に信頼できる公開を開始しました。これは Trail of Bits によって構築され、Google のオープンソースセキュリティチーム（Open Source Security Team）の資金提供を受けています。RubyGems.org は 2023 年 12 月に追随し、npm は 2023 年に Sigstore を介してプロベナンスアテステーション（provenance attestations）を、そして 2025 年 7 月に完全な信頼できる公開を実装しました。crates.io も 2025 年 7 月に開始され、NuGet は 2025 年 9 月に追随しています。現在、PyPI のアップロードの 25% 以上でこの仕組みが利用されています。 プロベナンスにより、パッケージが特定のコミット abc123（github.com/foo/bar）から構築されたことが判明すれば、 Google の OSS Rebuild OSS Rebuild は、Google のオープンソースセキュリティチームによって 2025 年 7 月に発表されました。これは、ほとんどのビルドがまだビット単位で再現可能ではないという事実に実用的なアプローチを採用しています。具体的には、パッケージをソースから再構築し、タイムスタンプやファイル順序といった既知の不安定要素を正規化した上で、意味のあるコンテンツが一致するかどうかを検証します。 開始当初、この取り組みは PyPI、npm、crates.io にわたる数千のパッケージをカバーしており、公開されたメタデータからビルド定義を推論するための自動化とヒューリスティックを使用し、コンテナ内で再構築を行い、Sigstore を介して署名された SLSA Level 3 のプロベナンス証明（provenance attestations）を公開していました。安定化 Matthew Suozzo 氏の FOSDEM 2026 での講演は、純粋な再現可能性を超えてビルドの可観測性へと踏み込み、隠れたリモート依存関係を検出するためのネットワークプロキシと、ビルドが実際に実行時に何を行っているかを回答するための eBPF ベースのビルドトレーシングを追加しました。これは、出力が決定論的であるかどうかに関わらず、独立して有用な情報です。 現状 言語パッケージマネージャーは、Debian がビルドインフラストラクチャを制御しその環境への変更を義務付けられる一方で、言語レジストリはどこからのアップロードも受け入れ、歴史的にアーティファクトがどのように生成されたかを知る手段を持っていなかったため、Linux ディストリビューションに比べて再現可能なビルドにおいて数年分の遅れがあります。信頼できる公開（Trusted publishing）は、レジストリがプロセスを把握できるようになるよう、ビルドをローカルマシンから CI 環境へ移行させることでこの状況を転換しています。これにビルドのプロベナンスと SLSA 証明を組みわせることで、ビルドツール自体が追いついていない場合でも、独立した検証が可能となる条件が整います。Go はコンパイラを決定論的にすることでその地位を確立しましたが、これは最もクリーンな解決策である一方で、最初からツールチェーン全体を制御する必要があります。

言語パッケージマネージャーにおける再現可能なビルド

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト