Status update about reproducible live-build ISO images in Jenkins

[Roland Clobus]

Hello list,

here is a quick update of the status for reproducible live-build ISO images.

* With the help of Holger Levsen, I implemented the first test running
in Jenkins [1][2], based upon my previous work [3].

The Jenkins job:
* Uses the latest-and-greatest version of live-build, i.e. the master branch
* Uses the necessary tweaks to make the image reproducible from [3]
* Builds the smallest live-image configuration possible by live-build, twice
* Compares both ISO files with diffoscope
* Stores the output of diffoscope in [2]

The result shows that the ISO files are identical. Hurray!

You can stop reading here if you want...

Weak points and Future plans:
* Both images must be built within the same mirror-sync time, otherwise
the timestamp inside the '_InRelease' file in /var/lib/apt/lists will differ
** This can be solved by using snapshot.debian.org, which will guarantee
identical downloads every time
** However, #960304 [4] describes that this service is under heavy load,
though the strategy from comment 18 might be used to work around this
** Question: could/should Jenkins use snapshot.d.o?
** Because the job is currently triggered on a daily basis, Jenkins
could also verify the reproducibility compared to its previous run (see
below)
* The ISO images are built with similar environment
** reprotest can be used, which allows for more variations during building
** Initial investigations for reprotest are in [3] and some variations
that need to be turned off are listed there too
* The output page after a success is rather minimal
** (Nearly) All info to reproduce the build is stored in the Jenkins
console output, but that is <understatement>not always nice to
read</understatement>
** The timestamp of the used mirror is not visible anywhere
* In addition to the minimal build, the major 7 desktops and a text-only
image, similar to the current live images [5] need to be built
** When run concurrently, this would consume a lot of harddisk space
(during the build, an uncompressed chroot is needed)
* The generated ISO files are currently thrown away after a build
** They could be stored, because:
*** When a difference is detected, it is convenient to have exactly the
situation that caused the difference
*** A later run of the Jenkins job could verify changes made by/after
the next mirror synchronisation
** However, a desktop image is about 2.5GB, the standard image 1.0GB,
the minimal image 240MB
*** This would require 7x2.5+1+0.24~19GB (possibly times 2 when a
difference is detected) space that would be semi-permanently occupied
*** Question: Is this amount of space available?
* I would like to test the functionality of the generated ISO image.
** I've read about the approach by Tails, that looks really promising
(and cool) [6]
** That could alleviate the burden during releases a lot
* Note that the current live images are generated with 'live-wrapper',
which is another tool than 'live-build'
** Some discussion was started some time ago, I personally think that an
automated (easy to manage) test suite would be beneficial

With kind regards,
Roland Clobus

[1] https://jenkins.debian.net/job/reproducible_debian_live_build
[2]
https://tests.reproducible-builds.org/debian_live_build/smallest-build.html
[3] https://wiki.debian.org/ReproducibleInstalls/LiveImages
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960304
[5] https://cdimage.debian.org/debian-cd/current-live/amd64/iso-hybrid/
[6] https://tails.boum.org/contribute/release_process/test/automated_tests/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20210627/adb55017/attachment.sig>