"Reproducible build" definition in OpenSSF glossary

[Simon Josefsson]

"Arnout Engelen" <arnout at bzzt.net> writes:

> On Tue, Jul 1, 2025, at 09:59, fosslinux via rb-general wrote:
>> On 6/30/25 17:29, Ismael Luceno wrote:
>> >> 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.
>> 
>> Any suggestions for what to call it? There is value to such work, and it is at minimum very closely related to 
>> reproducible builds.
>
> I think it's pretty much impossible to avoid people 'maliciously'
> misrepresenting their product as 'reproducible' when it really isn't -
> that doesn't seem like something tweaking the definition can fix. I do
> think it's still useful to have precise terms so we can make the
> distinctions clear, though.
>
> I agree "Reproducible Builds" as a whole means "from source to binary".

That would make Debian installer CDs impossible to call reproducible,
since they are built from binaries for which we do not have source code.

So while I really agree with your goal, and would like that to exist
(distributions like Trisquel is a way forward here), I'm not sure
throwing out the baby (Debian) with the bath water here is a good idea.

It seems more inclusive to find a term for how the Debian LiveCD build
process actually look like, and create a rigid definition for it so we
can measure things.  Most people use the term "reproducible build" for
that process today.

> That often means making many steps in a larger process
> reproducible. I'm OK with statements like "this build step is now
> reproducible" or even "this build process is now reproducible" even
> when it still relies on binary/non-reproducible inputs. However,
> before saying "this build is reproducible" (or "this artifact is
> reproducible") I'd expect the whole 'chain' to be reproducible - and
> ideally we should also call that out when making statements about your
> build process being 'reproducible'. I could also see "This artifact is
> reproducible, except for binary blobs X, Y and Z" (but not "This build
> is reproducible, except for some timestamps").

Indeed, the devil is in the details here...  and finding a rigid
definition of the terminology.

> As for Leo's efforts painstakingly recreating a binary where upstream
> isn't interested in reproducible builds: I can see how it's useful,
> but I don't think it's "reproducible builds": a 'reproducible build'
> implies a repeatable process, not a one-off verification. Moreover
> when "signatures or compression might differ" that further deviates
> from "Reproducible Builds". I think it might still be reasonable for
> them to say "we have reproduced this artifact" (though 'recreated'
> might be clearer?), but it should not link to "Reproducible Builds".

Are you talking about upstreams who publish source+binaries or only
sources?  If upstream publish source code only, the whole concept of
"reproducible build" is mostly outside of their scope (to produce source
code), and I think we could talk about a reproducible build.

/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/3b656ca4/attachment.sig>