バージョン情報(Version information)
ソフトウェアに埋め込むバージョン情報は、決定論的に決まるようにしなければなりません。 現在日時や逐次増加するビルド回数を使用するのとは完全に逆の方法です。
ビルドした日付と時刻には、リリースしてから長期間経過しても古いソースコードをコンパイルできるかどうかを示すような価値はありません。 どのソースコードでビルドしたのか最も上手く説明できるのはバージョン情報なのです。
バージョン番号は、ソースコードと別のファイルから取得する場合があります。 変更履歴(Changelog) やバージョン管理システムです。 それぞれから、日付も抽出できるでしょう(必要なら)。
Git のチェックサム
バージョン管理システムの暗号学的ハッシュ関数に基づくチェックサムで、ソースコードの同一性を証明出来る場合があります。 バージョン情報の要素として Git のコミットIDは適切な候補です。
しかし、git describe
や git rev-parse
で取得した短縮形のハッシュ値が、ビルドの再現性を損ねてしまう場合があります。
短縮形のハッシュ値に含まれる16進数表記の文字数は、Git リポジトリに存在するオブジェクト数に依存する からです。
オブジェクト数が変化する要因は時間経過(任意のブランチに対する新しいコミットが増える)だけではありません。
例えば git-clone(1)
で浅い(shallow)クローンをすると劇的に変化します。
オブジェクト数が少数になるよう設計しているからです。
git-config(1)
のマニュアルページを引用しておきます。
core.abbrev
オブジェクト名を短縮形にするときの長さを設定します。 未指定の場合は “
auto
” が設定されたことにします。 その場合、リポジトリに存在する pack オブジェクト数の近似値に基づいて適切な値を算出します。 短縮形にしたオブジェクト名が重複しないために必要十分な長さになるはずです。 “no
” にすると、オブジェクト名を短縮せず、元の長さのまま扱うようになります。 最小値は 4 です。
従って、短縮形のハッシュ値をバージョン情報に使用するときは、この設定を固定値(あるいは “no
“)にすることをお勧めします。
例えば、コマンドを実行するときは git describe --abbrev=12
git rev-parse --short=12
としたり、core.abbrev
を設定したりするといいでしょう。
Introduction
Achieve deterministic builds
- SOURCE_DATE_EPOCH
- 確実なビルドシステム(Deterministic build systems)
- 揮発性のある入力データは消える場合がある(Volatile inputs can disappear)
- 入力データの順序を固定する(Stable order for inputs)
- 値を初期化する(Value initialization)
- バージョン情報(Version information)
- タイムスタンプ(Timestamps)
- タイムゾーン(Timezones)
- ロケール(Locales)
- アーカイブのメタデータ(Archive metadata)
- 出力データの順序を固定する(Stable order for outputs)
- 無作為性(Randomness)
- ビルド時のファイルシステムパス(Build path)
- システムイメージ(System images)
- JVM
Define a build environment
- ビルド環境に含む要素(What's in a build environment?)
- ビルド環境を記録する(Recording the build environment)
- ビルド環境の定義における戦略(Definition strategies)
- Proprietary operating systems
Distribute the environment
Verification
Specifications
Follow us on Twitter @ReproBuilds, Mastodon @reproducible_builds@fosstodon.org & Reddit and please consider making a donation. • Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. • Patches welcome via our Git repository (instructions) or via our mailing list. • Full contact info