Why do identical source commits produce different release binaries?

Identical source commits produce different release binaries because the build input is larger than the Git commit. If the process reads the clock, embeds absolute paths, depends on locale or timezone, packages files in unstable order, consumes randomness, or runs with a different compiler or archiver, the output changes even when the source tree does not. The practical fix is to run two isolated builds, compare bytes, and then eliminate each nondeterministic input in turn using the Reproducible Builds documentation.

What should you test first?

Build the same commit twice in clean, separate workspaces. Keep the source identical, but record the full build boundary: compiler, linker, packager, dependency lockfile resolution, OS image, environment variables, locale, and timezone. Then compare the final artifacts byte-for-byte.

This matters because the recurring variance sources are already well documented: the Reproducible Builds documentation explicitly calls out timestamps, timezones, locales, archive metadata, stable output order, randomness, and build path. That is the decision criteria for your investigation: if a binary differs, assume one of those inputs changed until proven otherwise.

Which inputs usually change the bytes?

Start with timestamps. If your build embeds a generated date, archive member mtime, image creation time, or release metadata derived from the current clock, two builds will diverge. The SOURCE_DATE_EPOCH documentation defines it as a “standardised environment variable” that tools can consume “to produce reproducible output.” It also notes that UTC matters when rendering dates, which is why timezone differences can leak into binaries.

Next, check path leakage. Absolute workspace paths often appear in debug symbols, manifests, or generated files. A build in one directory and the same build in another can therefore change the artifact without any source change.

Then check ordering and locale. If a tarball, ZIP, or generated file list follows filesystem iteration order instead of a sorted order, archive bytes change. Locale-sensitive sorting can make that worse: the same filenames can be ordered differently under different locale settings.

Finally, verify the toolchain itself. A different compiler patch release, archiver implementation, container base image, or dependency selection can change code generation or packaging output.

How do you isolate the exact cause?

Use this checklist in order:

1. Rebuild the same commit twice in separate clean environments.
2. Compare final artifacts and key intermediates.
3. Export a fixed SOURCE_DATE_EPOCH derived from the commit history or release input.
4. Set timezone and locale explicitly, such as UTC and LC_ALL=C, if your tooling permits.
5. Sort packaging inputs before creating archives.
6. Rebuild in two different directories to expose path leakage.
7. Pin the toolchain and dependency resolution inputs.

Worked example: suppose two CI jobs produce different release.tar.gz files from the same tag. First fix SOURCE_DATE_EPOCH and rebuild. If the hash still differs, force a sorted file manifest before tar creation. If it still differs, rebuild once under one workspace path and once under another. If only the path change reproduces the diff, you have embedded build-path data rather than a source-level problem.

How can we find what makes builds nonreproducible?

Treat it as a controlled experiment, not a code review exercise. Change one build input at a time and keep the build boundary explicit. Produce the unsigned artifact you intend to compare deterministically, including packaging when it is part of that artifact, then perform optional signing or publication afterward. If your team mixes reproducible build steps with intentionally changing release-time metadata, the investigation gets noisy fast.

What should the team verify before adopting this workflow?

Verify that you can name the artifact boundary you expect to reproduce, pin the toolchain used to create it, and rerun that process in isolation. If signatures, attestations, or external timestamps are required, keep them outside the reproducible boundary and compare the pre-signing artifact.

Next step: add one CI job that rebuilds a tagged commit twice in isolated workspaces and fails if the unsigned artifacts differ.

Reviewed: 2026-09-05