Cryptographic checksums

How can users know that the build they just made has successfully reproduced the original build?

The easiest way is to make sure that the build outputs are always byte-for-byte identical. Byte-for-byte comparison is a trivial operation and can be performed in many different environments.

The other benefit of having identical bytes is that it makes it possible to use cryptographic checksums. Such checksums are really tiny compared to the full build products. They are easily exchanged even in very low bandwidth situation.

For example, it makes it possible to build a software release both on a well-connected (but hard to trust) server and on a laptop behind a bad mobile connection. The digital signature can be made locally on the laptop. As the build products will be identical, the signature will be valid for the files produced on the well-connected server.

---

← Documentation index

Documentation home

Introduction

• 定義（Definitions）
• History
• やってみる（Buy-in）
• 計画する（Making plans）
• Academic publications

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

• ソースコードからビルドする（Building from source）
• Virtual machine drivers
• Formal definition

Verification

• Cryptographic checksums
• Embedded signatures
• Sharing certifications
• Rebuilders

Specifications

• SOURCE_DATE_EPOCH
• BUILD_PATH_PREFIX_MAP (WIP)