Timo Pohl <[email protected]> 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
signature.asc
Description: PGP signature
