"Reproducible build" definition in OpenSSF glossary

[David A. Wheeler]

> On Apr 25, 2025, at 7:36 AM, Holger Levsen <holger at layer-acht.org> wrote:
> 
> On Thu, Apr 24, 2025 at 05:38:54PM +0200, Simon Josefsson via rb-general wrote:
>> I like it, but one question about the new addition of "source code":
>> 
>>> Reproducible builds are a set of software development practices that
>>> create an independently-verifiable path from source code to build
>>> artifacts (e.g., binary code) that counters attacks on the build
>>> process.
>> ...
>>> Source code is the preferred form of the work for making modifications to it. It is usually a checkout from version control at a specific revision of a source code archive.
>> 
>> This imply to me that the Debian live CD is not reproducible.  It was
>> not built from source code and, even further, we don't even have access
>> to source code for some of the non-free parts, so we cannot build it
>> from source code.  Is that what you intend?

The *current* definition of reproducible builds says "source" meaning "source code".
I believe that under the *current* definition of reproducible-builds.org <http://reproducible-builds.org/>, the Debian Live CD
is not reproducible. I suspect many people *would* accept the Debian Live CD
as reproducible, but we'd need to modify the
reproducible-builds.org <http://reproducible-builds.org/> definition to fix that.

How about replacing "souce code" with "build inputs (e.g., source code)"?
The first sentence then becomes:

> Reproducible builds are a set of software development practices that
create an independently-verifiable path from build inputs (e.g., source code)
to build artifacts (e.g., binary code) that counters attacks on the build
process.

There might need to be some clarifying text later. Here's one try:

> Most builds convert source code into a compiled executable form (e.g.,
executable(s) or a package containing executable(s)). Some builds convert other
build inputs (such as an executable or package) into other kinds of build artifacts
(such as a container, filesystem, or ISO image). No matter what, a verified
reproducible build verifies that the build inputs reproducibly produce the build artifacts
for that specific build process. We permit higher-level builds to use build inputs
that are not reproducible, e.g., due to closed-source drivers, but those build inputs
present a higher risk since they cannot themselves be reproduced.

On Apr 25, 2025, at 7:30 AM, Holger Levsen <holger at layer-acht.org> wrote:

> I do agree that having two definitions on our website is bad or sub-optimal
> and would welcome patches (and/or discussions in an MR as opposed to this list,
> though obviously its great to use this list to prepare such an MR) to address
> that. I also do think that https://reproducible-builds.org/docs/definition/ 
> should have our definition because thats a stable URL since almost 10 years.

Yes, eventually this needs to become an MR & there will be more discussions there
I'm sure :-). *However*, clearly defining the key term for this *entire* project & effort
is really important. I'd like to have maximal awareness, review, & buy-in.
Once there seems to be general agreement on this mailing list I'd be happy
to create the initial proposed MR. I'm sure some will comment there too, but
I want to make sure that we've ironed out many issues *before* that.

--- David A. Wheeler