Reproducible Firmware Build

主張の対象はファームウェアイメージなどの指定された出力であり、すべてのファイルやログに自動的に及ぶわけではありません。同じ動作だけでは不十分で、通常は暗号学的ハッシュを用いて同じバイト列を確認します。ソースが公開されていてもビルドを再現できなければ、公開バイナリとの対応関係はそれだけでは示せません。 [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]

正確な commit、依存関係とそのバージョン、コンパイラ、ビルドオプション、関連する環境変数、対象機種を記録します。プロジェクト名や変動するブランチ名だけでは不十分です。再実行に必要な情報は公開するか、ビルド時に記録しなければなりません。そうでなければ差異を確実に評価できません。 [Reproducible Builds — Definition] [Reproducible Builds — Recording the environment]

コンパイラは作業ディレクトリのパスをデバッグ情報に埋め込むことがあります。同じソースを別の場所に置くと異なるファイルができる場合があります。パスは事前に指定するか、対応する方法で正規化できます。この規則はビルド手順の一部でなければならず、後から不明な差異を削除すると検証が無意味になります。 [Reproducible Builds — Build paths]

有効な署名は、ある信頼モデルのもとで公開物を対応する署名鍵に結び付けます。独立したビルドは、ソースとバイナリ出力の関係を調べます。公式の署名付きファイルには、ローカルの未署名ビルドにないデータが含まれることがあります。そのためファイル全体の単純比較が、主張された再現性の正しい検査になるとは限りません。 [Trezor — Reproducible build verification]

Trezor の文書ではバージョンと機種を選び、指定環境でイメージを作り、公式公開物と比較します。比較前に厳密に定義された署名フィールドをゼロにする手順があり、古い形式ではヘッダーも異なります。構造は機種とバージョンに依存します。あるイメージの手順を別のものへ無条件に適用してはならず、元の署名は別途検証します。 [Trezor — Reproducible build verification]

まずリビジョン、機種、ファームウェアの種類、依存関係、宣言済みのイメージ変換を確認します。元のファイルと差分記録を保存します。不一致は手順や環境の誤りでも、配布バイナリの変更でも生じ得ますが、それだけで原因は決まりません。差異を説明し検査を繰り返すまで、出力を検証済みとしてはいけません。 [Reproducible Builds — Definition] [Reproducible Builds — Build infrastructure threats]

欠陥や悪意のあるソースでも完全に再現可能な場合があります。共通の信頼できないコンパイラが全結果に同じ変更を挿入することもあり、同じツールの再実行は独立したコンパイラ監査ではありません。非公開のバイナリ部品があると、利用可能なソースから再構築できる範囲は限られます。ファイルの一致は、ハードウェアの真正性や特定の機器に実際に入っている内容も確認しません。 [Wheeler — Countering Trusting Trust] [Reproducible Builds — Definition]

有用な記録には、誰が、どの commit から、どの手順で、どの機種向けにビルドし、どのファイルを比べたかを記します。ハッシュ方式、結果、署名データに関する厳密な例外範囲も添えます。独立したビルド実行者が増えると単一の配布者への依存は減りますが、ソース、更新手順、機器全体の安全性の確認を置き換えるものではありません。 [Reproducible Builds — Recording the environment] [Reproducible Builds — Build infrastructure threats]