"Reproducible build" definition in OpenSSF glossary

[David A. Wheeler]

> On May 11, 2025, at 5:14 PM, Vagrant Cascadian <vagrant at reproducible-builds.org> wrote:
>> Any strong objections to merging this?
> 
> I think we need considerably more time and possibly a (semi)formal
> process to think over the potential ramifications of the changes. This
> is not just some grammar and typo corrections or fleshing out some new
> angles on reproducible builds; it is something fundamental and essential
> to our project.

I understand. My fear is that this will linger forever. I suggest setting
a deadline for comments. May 22, maybe? I don't care about the deadline,
but I'd prefer to get this done before I die of old age :-).


> 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.

I understand. So what's the consensus? Is source code required or not?
It'd be easy to revert back to the "source code required" version.

I would be fine with requiring source code
*if* we also defined another term for what the Debian folks are doing with images.
They're doing awesome work, it's clearly related to reproducible.
Regeneratible builds? Regenerable images?

> I do not think we have a fundamental problem with having two definitons
> of what a Reproducible Build is; we have one definition:
> 
>  https://reproducible-builds.org/docs/definition/
> 
>  "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.
> 
>  The relevant attributes of the build environment, the build
>  instructions and the source code as well as the expected reproducible
>  artifacts are defined by the authors or distributors. The artifacts of
>  a build are the parts of the build results that are the desired
>  primary output."
> 
> The description on the front page:
> 
>  https://reproducible-builds.org/
> 
>  "Reproducible builds are a set of software development practices that
>  create an independently-verifiable path from source to binary code."
> 
> Seems to me more a description of what the Reproducible Builds project
> is working on to achieve the sorts of things spelled out in the
> Reproducible Builds definition. Making it more clear it is about the
> project might be a good idea!

I'd argue that if you say "Regenerable builds are...", what follows is a definition,
whether or not you *intended* it to be a definition :-). It walks way too much
like a duck.

I think both phrases are useful. The front page definition focuses more on
the goal, but never mentions bit-for-bit (which is *key*). The more detailed
definition focuses on what to do, but not why. I recommend merging them.

> I would be much more amenable to accepting simple changes to the
> description(s) and other messaging about what the project does, but I do
> not want to rush changes to the Reproducible Builds definition.

We can do that, but if we do, we explicitly make the image recreation
work *not* reproducible builds. In that case, I think we need another term,
because they're doing good work & deserve a term for what they're doing.

--- David A. Wheeler