"Reproducible build" definition in OpenSSF glossary

[Simon Josefsson]

Timo Pohl <pohl at cs.uni-bonn.de> writes:

> I have been thinking about this for a bit myself, and at least from
> the point of view of someone trying to verify reproducibility of a
> certain build, i would say the environment is definitely necessary,
> and if anything the current definition is too unspecific to allow
> generic verification.
>
>> What matters is that someone is able to get the same bit-by-bit
>   identical output.
>
> I would argue that what's relevant is that *everyone* is able to get
> the same bit-by-bit identical output. Without specifying the relevant
> parts of the environment, you quickly get into a situation where some
> rebuilders happen to have an environment where the output artifact is
> the same, while others with a different environment get a different
> artifact. In my opinion, the inputs for a "reproducible build" should
> be specific enough so that anyone adhering to these inputs gets the
> same artifact out, and you don't need to get lucky, or get additional
> information from somewhere else to successfully reproduce the same
> artifact.

Agreed -- what I use (and would recommend as a minimum) in software
release announcements is to include the version of all tools used, see
last part of some recent announcement:

https://lists.gnu.org/archive/html/help-libtasn1/2025-02/msg00000.html

Relevant part quoted below.

The versioning information is sufficent to be able to reproduce the GNU
Libtasn1 v4.20.0 source tarball from the git repository: install those
tools in any environment that is able to run libtasn1's './bootstrap &&
./configure && make && make dist', from the git tag commit, and you
should end up with exactly the same tarball.  Or there is a bug that
ought to be fixed.

Assembling this in an automated fashion (and verifying it in CI/CD!) is
a lot of work.  Gnulib's announce-gen script helps here (it is
responsible for generating the entire announcement e-mail).

Debian's *.buildinfo files provide similar versioning information for
binary packages, but accessing them is harder than it should be.

However I think it is fine if you manage to use some other build
environment and also happen to end up with the same release artifact.
That is still a reproducible build.  You don't HAVE to install the exact
same version of all those tools, you can get lucky with other versions
too.  But the information is there if you want to make an effort.

/Simon

This release is based on the libtasn1 git repository, available as

  git clone https://gitlab.com/gnutls/libtasn1.git

with commit 6b45b25e94ea538192cc0f97e9ad57171d1c6374 tagged as v4.20.0.

For a summary of changes and contributors, see:

  https://gitlab.com/gnutls/libtasn1/-/commits/v4.20.0

or run this command from a git-cloned libtasn1 directory:

  git shortlog v4.19.0..v4.20.0

This release was bootstrapped with the following tools:
  Gnulib 2025-02-01 c89cd2fbd3b9f3d7c5a146247256599714c91ec7
  Autoconf 2.71
  Automake 1.16.5
  Libtoolize 2.4.7
  Make 4.3
  Makeinfo 7.1.1
  Bison 3.8.2
  Help2man 1.49.2
  Gtkdocize 1.33.1
  Tar 1.34
  Gzip 1.13
  Guix d48da2d21610f9cf5f76cd846703b12beedb1fd5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1251 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20250423/faeddceb/attachment.sig>