"Reproducible build" definition in OpenSSF glossary

[Simon Josefsson]

"David A. Wheeler via rb-general"
<rb-general at lists.reproducible-builds.org> writes:

>> On May 11, 2025, at 5:14 PM, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
>> The definition as it stands does have some oddness when considering
>> things like system images, container images, etc. and I feel very mixed
>> about letting go of the focus on source code, even though I do think
>> there is space to call some of these usefully reproducible, I very much
>> worry about dilluting the Reproducible Builds definition too much to
>> accomodate them; I have the strong suspicion there will be unintended
>> consequences.
>
> Do others also have that concern?
>
> If so, there's a simple solution: Use the two original definitions
> of reproducible builds (combined so they don't conflict) that *require*
> source code, and provide a new term for the case where you don't necessary
> have source code (for the Debian ISO case). I suggest calling these
> "regeneratable builds" and make it clear that these two ideas are
> very similar but not *exactly* the same.
>
> Would that be better?

I think it would help to have different terms for these two concepts.

I also think that getting the definitions right is complicated, and I
share the suspicion that there may be unintended consequences.

However we already have this today: is the Debian Live CD "reproducible"
or not?

I think the current definition imply no, but I think people want this to
be yes.  Or at least to have some term to recognize the nice property
that the Debian Live CD have.

Perhaps introducing Holger's (?) term of a "reproduced" build can help.

Here is a strawman "Taxonomy Of Build Artifact Properties":

same build = a skilled person can re-create equivalent (under some
reasonable definition of equivalence) but not bit-by-bit identical
artifacts from a set build instructions and some fixed inputs (files
with known checksums) which may or may not be source code in the sense
of being in a preferred form for making modifications to.  An example of
this is rebuilding GNU Autoconf and getting an output artifact that
differs only due to embedded timestamps.  Or re-creating an AI model
from some training data, to connect with a recent discussion.

reproduced build = a skilled person can re-create bit-by-bit identical
artifacts from a set build instructions and some fixed inputs which may
or may not be source code in the sense of being in a preferred form for
making modifications to.  An example of this is the Debian live CD.

reproducible build = same but we are building the essential part of the
work from source code, but accept that build dependencies are binaries.
This is what Reproduce.Debian.Net is doing.

bootstrappable build = same as reproducible but we are building both the
essential part of the work and all the necessary build dependencies from
source code, back to a small source code seed.

idempotent build = same as reproducible but a further guarantee that the
output artifact remain bit-by-bit identical even when all of the build
dependencies are themselves re-built from source using the output
artifact as an input when re-building the build dependencies,
iteratively until no further changes occur.  This property guarantee
that the resulting system can rebuild itself identically.

perfect build = both bootstrappable and idempotent :)

All of this has to be possible to do on a machine not connected to any
network, i.e., we don't permit random downloads during the build and
that all necessary inputs are known before the build starts.

Licensing for all inputs is orthogonal to this, but practically
important.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20250516/90396bbb/attachment.sig>