"Reproducible build" definition in OpenSSF glossary

[John Gilmore]

fosslinux via rb-general <rb-general at lists.reproducible-builds.org> wrote:
> 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.

I recommend that you find a project that is more compatible with your
own goals.  This one does seek to have maintainers of both individual
programs, and operating systems, produce bit-for-bit reproducible
results from human-readable source code, which end-users can easily
verify, with automation for doing rebuilds and comparing them.

I think that the work that you like to do (about verifying binaries that
were not designed to be reproducible) is valuable.  See also, for
example, the Software Freedom Conservancy's efforts to verify that the
source code released for GPL'd embedded-system binaries is sufficient to
reproduce them -- https://sfconservancy.org/usethesource/ .  These
efforts are valuable, but are not the work of this project.

People contribute to the world in many ways.  It has turned out to be
quite a challenging many-year job just to marshal the efforts of the
thousands of maintainers who DO desire their work to be reproducible, or
who are happy to accept patches for that effect.  And collaborating with
donors of money, work and infrastructure who think that instilling a
culture of traceability of binaries back to matching source code is
valuable for security and freedom.  There are often invitations to
reduce the guarantees that this project is trying to offer, or to dilute
the value of the term of art that this project settled on ("reproducible
builds") by applying it to things that aren't designed or intended to be
reproducible.  Please observe our work as much as you like, and
contribute to it when you can, but please don't try to steer us into
solving a different problem.

Thank you.

	John Gilmore