"Reproducible build" definition in OpenSSF glossary

fosslinux fosslinux at aussies.space
Wed Apr 23 11:40:40 UTC 2025


Hi Thomas, Roland and list,

Thank you for the insights - for the reference of all interested, I was particularly referring to the list thread with 
subject "Irregular status update about reproducible Debian live ISO images" particularly 
https://lists.reproducible-builds.org/pipermail/rb-general/2025-March/003680.html onwards.

For clarity: I am not making any commentary upon the Debian live ISO images in particular! Just using them as an example 
to my point.

On 23/4/25 21:17, Thomas Schmitt via rb-general wrote:
> For "live-build" there is
>    https://wiki.debian.org/ReproducibleInstalls/LiveImages
> saying:
>    Status
>    Bookworm: All official images are reproducible (the live-build stage)
>    Trixie: All unofficial images are reproducible (the live-build stage)
On 23/4/25 21:21, Roland Clobus wrote:
> Additionally I've sent an update of my first, bold mail to this list 
> https://lists.reproducible-builds.org/pipermail/rb-general/2025-April/003700.html which identifies me at the person 
> making the claim within a specific context ('the author'), therefore fulfilling every aspect of the current definition 
> of 'reproducible builds'.

Before I explain, to be entirely clear, my viewpoint is that the definition *should* define Roland's excellent work on 
the Debian live ISOs as being reproducible. But, I'm currently unsure that David's definition strictly permits this:

"A build is /reproducible/ if given the same source code, build environment and build instructions, any party can 
recreate bit-by-bit identical copies of all specified artifacts. This creates an independently-verifiable path from 
source to binary code and counters attacks on the build process."

With reference to Roland's update,

On 7/4/25 00:26, Roland Clobus wrote:
> According to the definition [8] the live images are reproducible, given that the author (me) states:
> * The source: the online Debian archive consisting of .deb files and corresponding metadata
> * The build environment: A Debian installation of either bookworm or testing with the rebuild.sh script from [9] 
> matching the sha256sum of the official images (see their .disk/generator file) and the tool live-build installed
> * The build instructions: See [4], i.e. using the same command line options to rebuild.sh as in .disk/generator
> * The artifact: the ISO file 

yet David's definition does not read to me that "the online Debian archive consisting of .deb files and corresponding 
metadata" fits into the definition, as (uncontrovertially) a .deb file is *not* "source code; that's why I suggest the 
alternative term "identified set of source material", which would squarely place "the online Debian archive consisting 
of .deb files and corresponding metadata" as the identified "source material".

As a second example, I fully agree with Thomas' statement

On 23/4/25 21:17, Thomas Schmitt via rb-general wrote:
> xorriso supports reproducibility of its results
but again, this use of "reproducibility" does not fit into David's definition, because there is no clear "source code" 
input into xorriso, but it would fit into my slightly modified definition, by letting "identified set of source 
material" = input, "build environment" = xorriso + libraries, SOURCE_DATE_EPOCH, "artifact" = produced ISO image.

On 23/4/25 21:21, Roland Clobus wrote:
> This discussion reminds me of a discussion that was held in Debian some time ago [citation needed] about which files 
> are to be considered source code. Please don't go there again 🙂

We don't need to go there, particularly not in this thread, as long as we agree that a .deb file is not "source code" :)

On 4/23/25 21:21, Roland Clobus wrote:
> Finally, I think the reproducible effort can have both a top-down and bottom-up strategy implemented at the same time. 
> Both strategies involve a lot of effort to make them work. I know for sure that making reproducible live images has 
> taken a lot of effort. 

Absolutely agreed! So let's have a definition that clearly defines top-down work as progress toward reproducibility. :D

Kind regards,

Samuel

(Thanks to Roland and Thomas for their contributions to the r-b sphere!)



More information about the rb-general mailing list