Eliminating Timestamp Drift in Binary Release Checksums

Timestamp drift breaks reproducible builds

Two identical git commits produce different tarball hashes on two machines. The source tree has not changed. The checksum verification step reports a mismatch. The cause is hidden metadata: file timestamps and archive entry order. When the packaging tool writes the archive, it records the current clock value for each file. The order in which the filesystem yields entries can vary with the underlying OS and hardware. Those tiny differences change every byte of the archive. The result is a failure of deterministic software expectations. The problem surfaces in CI pipelines that compare artefacts across runners, and in downstream consumers that cache release archives by checksum.

Clamp timestamps and normalise order

The fix is to make the archive creation command deterministic. Use GNU tar’s --mtime flag to set a fixed modification time for every file. Choose an epoch that is easy to read, for example 1970-01-01. Pass --sort=name to force alphabetical entry order regardless of filesystem layout. Finally, strip owner and group information with --owner=0 --group=0 and set a constant numeric mode with --mode=0644. A minimal command that satisfies all three requirements looks like this:

tar --create \
    --file=release.tar.gz \
    --gzip \
    --mtime='1970-01-01' \
    --sort=name \
    --owner=0 --group=0 \
    --mode=0644 \
    .

The command writes the same byte sequence every time it runs on any platform, provided the input files are identical. No external entropy is introduced. The archive now passes checksum verification across machines and dates.

Verify reproducibility in CI

Add a step that computes the SHA‑256 of the produced archive and compares it to a stored reference. Store the reference hash in version control alongside the release script. In a CI job, run the tar command, compute the hash, and abort if it differs. The script can be as short as:

sha256sum release.tar.gz > current.sha256
git diff --quiet current.sha256 refs/heads/main:expected.sha256 || exit 1

If the job fails, the cause is a change in the source tree or a deviation from the deterministic flags. The failure mode is explicit: “checksum verification failed”. The remedy is to audit the build script for stray flags or environment variables that affect timestamps.

The approach aligns with the guidance in the pillar post /blog/why-model-independence-is-an-engineering-posture. Both stress that reproducible builds depend on owning every transformation step, not on external variance such as a model’s output.

SHPBL’s repeatable release pipeline

SHPBL supplies a model‑independent library that can be harvested from existing repositories. The library is computed rather than generated, and its release archives are sealed with published checksums. The same tooling flags described above are baked into the SHPBL build harness, guaranteeing byte‑for‑byte reproducibility for every artefact it ships. You can try the process on a sample repository via the free /evaluation lane, or adopt the full capability through the Practitioner tier. The harness records a verdict for each artifact, so you see at a glance whether a release is CERTIFIED or still PROVISIONAL. For details, see the SHPBL method page [/].

On Monday, replace your current tar command with the deterministic version above, add a checksum comparison step, and confirm that the same hash appears on both your local machine and the CI runner. If the hashes match, you have eliminated timestamp drift and restored reproducible builds.