"Reproducible build" definition in OpenSSF glossary

[fosslinux]

Hi all,

On 6/30/25 05:51, Ismael Luceno wrote:
> A wider definition threatens with a chasing game we don't want to play with upstream authors.
>
> We want people to, ideally, fix their buildsystems, and maintain that support forward.

Yes, in a perfect world, we want upstreams to always produce reproducible artifacts.

But someone has to actually *do this work*. And not everyone is convinced that reproducible builds are a priority or 
even necessary, unfortunately. So what are we to do with this?
Should we just say "ok, this upstream doesn't have the desire, or time, or resources to guarantee reproducible builds, 
therefore reproducible builds for this project are a lost cause"? This seems a very defeatist attitude to me.

> At some point it can be made a requirement, we don't expect to do any reverse engineering, and we don't want it to be an afterthought in the future.
>
> A narrow definition keeps those problems at bay as inherently out of scope.

I would push back on this as well as I do not think this is the place for a definition. This may be a _goal_, but it is 
not the _definition_ of a reproducible build. The definition should be clearly applicable to individual artifacts in my 
opinion, rather than merely projects as a whole. I think whether a project follows reproducible builds belongs to 
something more like OpenSSF scorecard.

I want to see a definition where I can go to a specific artifact/binary, read some associated documentation for that 
artifact/binary and say "yes, this is reproducible" or "no, this is not reproducible".

> Binary distributions should aim for the same experience source based distributions have been providing for 25 years, binary packages should act like an optimisation to skip the build more or less.
Are you talking about Linux distributions here? What does this have to do with reproducible builds? This sounds just 
like a very specific application of reproducible builds imo.
> So it isn't about verifying the work of any single maintainer, but ideally a distributed check on the whole ecosystem.

Expanding on my earlier comments, a "distributed check on the whole ecosystem" _is_ inheriently "verifying the work of 
any single maintainer" but doing that hundreds or thousands of times, in a repeated, (semi-)automated manner. You can't 
have a distributed check without verifying individual works.

-Samuel