"Reproducible build" definition in OpenSSF glossary

[Simon Josefsson]

Ismael Luceno <ismael at iodev.co.uk> writes:

> On 30/Jun/2025 08:59, Simon Josefsson wrote:
> <...>
>> When (re-)building the Debian LiveCD the "source code" is mostly
>> previously built binary packages.
>
> No, the source would be the source of every single binary, plus the
> ensemble and the steps to package it together at each level, like a
> matryoska.

That's not how the Debian LiveCD itself is built -- its build process
takes prebuilt binaries.  Those prebuilt binaries may or may not be
reproducibly built, and may or may not have source code available for
rebuilding.

You could say that the Debian LiveCD build process to include all build
steps of all involved binary packages, but I'm not convinced that is the
best way to tweak the terms and definitions.  Another approach is to
acknowledge that it is useful to find a term for how the current Debian
LiveCD build process works.

> <...>
>> some set of instructions and a set of opaque "source inputs" files which
>> may include previously built binaries, without any requirement that
>> those previously built binaries can be rebuilt or is even free software.
>
> That can't possibly qualify as reproducible.

I think that situation is what we have called reproducible for a long
time already.

>> An example of 1) is the Debian Live CD situation, it is reproducibly
>> built mostly based on previous binaries, and some of those binaries we
>> don't have source code for and they are not freely licensed.
>
> So you're asking to bend common sense so you can include proprietary
> drivers and/or firmware and call it "reproducible".
>
> That literally opens the door to call anything "reproducible".
>
> Maybe just label that as "I want to believe" builds instead.

I dislike binaries that are not built from source code using tools that
themselves where not built from source code.  But I believe there is
enough people interested in having a term for the above situation.  If I
understand Holger's description of the history correct, the above
situation is what we have been called reproducible for many years or
even since the start for reproducible Debian packages (that are built
using build dependencies that have some earlier build dependency from
seeds that have long since bit-rottened or are undistributable).

My interpretation of the history is that either we make people who like
the traditional de-facto definition of "reproducible" unhappy, or we
make more purist theoretical people who want a rigid definition of the
terms unhappy.  There are two ways out of this: 1) decide that one
interpretation is the Right One and say that the other is invalid and
incorrect, or 2) a more inclusive stance that encompass both approaches
and clarify terminology to find two different terms that describe each
of this two situations in a rigid way.

Personally I am a proponent of 100% free software and fully recursive
transitive rebuilds of binaries, but I perceive that many "reproducible
build" people dismiss these stronger notions and that this causes
friction and technical unclarity for a simple question like "is this
binary reproducible or not?"

> <...>
>
> Anyway, lot of clarification is in order.

+1

>> I don't think 2) necessarily requires recursive transitive closure of
>> the same requirement on all of the build inputs.  There are at least two
>> terms covering that additional requirement: A) "bootstrappable build",
>> which recursively rebuild things bit-by-bit identical back to a small
>> seed using earlier versions of software, and B) "idempotent rebuild",
>> which recursively bit-by-bit identically rebuild things using the latest
>> version of all involved tools.  Guix has proved A) is possible, but I'm
>> not aware of any proof that B) is possible with any modern non-trivial
>> OS.
>
> B would impose impractical implementation restrictions on the tools,
> but maybe a slightly weaker guarantee would be possible: keep track
> of a version of each involved package, check against that one, and if
> that works, create a derivative with the latest versions, which then
> automatically gets submitted somewhere for voting, if a threshold of
> agreement is reached, the new derivative can be automatically promoted
> as the new base for checking.

Yes, I'm seeing something like that for some future Debian unstable to
testing migration process.

For a binary to progress to 'testing', it has to be 100% bit-by-bit
identically rebuildable using the latest version (in 'testing') of all
build dependencies in a recursive way.

But we don't know x) if that situation is even possible to achieve
(there could be cycles of differences making this situation impossible),
and y) have no well-define process to resolve dead-locks where you need
to migrate a set of packages at the same time to achieve the desired
goal.

/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/20250702/62ade4f3/attachment.sig>