"Reproducible build" definition in OpenSSF glossary

Larry Doolittle larry at doolittle.boa.org
Tue Apr 29 18:16:37 UTC 2025


Matthew -

On Tue, Apr 29, 2025 at 11:55:40AM -0400, Matthew Suozzo via rb-general wrote:
> * A single example of a reproduction does not convey the ability for anyone
> to do the same, even given the same exact environment. Non-determinism in
> some input or in the build itself could spuriously cause a success in spite
> of the build not being reproducible to another party. I think the concept
> of reproducibility becomes blurry when we start considering many parties
> and diverse environments and so the idea of validating the property should
> reflect that.

Right.  Special case of the general rule "you can't prove a negative".

> * Whether it is practical to reproduce a build may (and, likely, will)
> change over time. Build inputs / environments may become unavailable or
> costly to acquire so it may not be feasible to verify a given artifact. The
> ability of someone to actively demonstrate a reproduction (maybe
> "verifiable" versus "verified") seems an equally valuable asset as the
> point-in-time measure that's currently proposed.

This ties to the general questions about software-supply chains.
I'm personally a big fan of Merkle Trees - specifically in this case
recording a secure hash (e.g., sha512sum) of all the the artifacts
that are considered input.  For actual source code, maybe it's enough
to capture the repository URL and git commit id.  For OS packages like
the compiler, we have .buildinfo (which includes SHA256).
Even if "you" don't have permission to redistribute a binary,
and just provide a URL to download it, its hash can still be part
of the instructions so that other people (and scripts) can confirm
the reproducible starting conditions.  Actually archiving old artifacts
is a separate problem.  IPFS?  (GD&R)

As tools change, sometimes that will break reproducibility, and sometimes not.
Do we have a concept of having a continuously updating list of environments
that are tested as successfully generating the same bit-for-bit output?

  - Larry


More information about the rb-general mailing list