Welcome to the February 2023 report from the Reproducible Builds project. As ever, if you are interested in contributing to our project, please visit the Contribute page on our website.
FOSDEM 2023 was held in Brussels on the 4th & 5th of February and featured a number of talks related to reproducibility. In particular, Akihiro Suda gave a talk titled Bit-for-bit reproducible builds with Dockerfile discussing deterministic timestamps and deterministic
apt-get (original announcement). There was also an entire ‘track’ of talks on Software Bill of Materials (SBOMs). SBOMs are an inventory for software with the intention of increasing the transparency of software components (the US National Telecommunications and Information Administration (NTIA) published a useful Myths vs. Facts document in 2021).
On our mailing list this month, Larry Doolittle was puzzled why the Debian
verilator package was not reproducible […], but Chris Lamb pointed out that this was due to the use of Python’s
James Addison also was having issues with a Debian package: in this case, the
alembic package. Chris Lamb was also able to identify the Sphinx documentation generator as the cause of the problem, and provided a potential patch that might fix it. This was later filed upstream […].
Anthony Harrison wrote to our list twice, first by introducing himself and their background and later to mention the increasing relevance of Software Bill of Materials (SBOMs):
As I am sure everyone is aware, there is a growing interest in [SBOMs] as a way of improving software security and resilience. In the last two years, the US through the Exec Order, the EU through the proposed Cyber Resilience Act (CRA) and this month the UK has issued a consultation paper looking at software security and SBOMs appear very prominently in each publication. […]
Tim Retout wrote a blog post discussing AlmaLinux in the context of CentOS, RHEL and supply-chain security in general […]:
Alma are generating and publishing Software Bill of Material (SBOM) files for every package; these are becoming a requirement for all software sold to the US federal government. What’s more, they are sending these SBOMs to a third party (CodeNotary) who store them in some sort of Merkle tree system to make it difficult for people to tamper with later. This should theoretically allow end users of the distribution to verify the supply chain of the packages they have installed?
Vagrant Cascadian noted that the Debian bookworm distribution has finally surpassed bullseye for reproducibility: 96.1% vs. 96.0%, despite having over 3500 more packages in the distribution.
Roland Clobus posted his latest update of the status of reproducible Debian ISO images noting that “all major desktops build reproducibly with bullseye, bookworm and sid,” with the caveat that “when non-free firmware is activated, some non-reproducible files are generated”.
FC Stegerman submitted a new Intent to Package (ITP) bug report representing an intention to package
repro-apk, a set of scripts to make Android
23 reviews of Debian packages were added, 24 were updated and 20 were removed this month adding to our knowledge about identified issues. A new issue was added and identified by Chris Lamb […], and the
timestamps_embedded_in_manpages_by_node_marked_manissue has been marked as resolved […].
F-Droid & Android
This month, F-Droid added 21 apps published with reproducible builds (out of 33 new apps in total), the overview of F-Droid apps published with Reproducible Builds now includes graphs, and there are now also some graphs of F-Droid apps verified by the Verification Server.
FC Stegerman noticed that signatures made by older versions of Android Gradle plugin cannot be copied because the signing method differs too much from that used by apksigner (and signflinger).
FC Stegerman also created a helpful HOWTO page on the F-Droid Wiki detailing how to compare and subsequently make APKs reproducible.
A long-running thread on Hiding data/code in Android APK embedded signatures continued on our mailing list this month; apksigcopier
v0.2.3were also announced on the same list.
Lastly, FC Stegerman reported two issues on Google’s own issue tracker: one related to a non-deterministic “Dependency Info Block” […] and another about a “virtual entry” added by the signflinger tool causing unexpected differences between signed and unsigned APKs […].
diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats.
This month, Chris Lamb released versions
236; Mattia Rizzolo later released version
- Chris Lamb:
- Fix compatibility with PyPDF2 (re. issue #331) […][…][…].
- Fix compatibility with ImageMagick version 7.1 […].
- Require at least version 23.1.0 to run the Black source code tests […].
debian/tests/controlafter merging changes from others […].
- Don’t write test data during a test […].
- Update copyright years […].
- Merged a large number of changes from others.
Akihiro Suda edited the
.gitlab-ci.ymlconfiguration file to ensure that versioned tags are pushed to the container registry […].
Daniel Kahn Gillmor provided a way to migrate from PyPDF2 to pypdf (#1029741).
Efraim Flashner updated the tool metadata for
isoinfoon GNU Guix […].
FC Stegerman added support for Android
resources.arscfiles […], improved a number of file-matching regular expressions […][…] and added support for Android
dexdump[…]; they also fixed a test failure (#1031433) caused by Debian’s
blackpackage having been updated to a newer version.
- Mattia Rizzolo:
- updated the release documentation […],
- fixed a number of Flake8 errors […][…],
- updated the autopkgtest configuration to only install
dexdumpon architectures where they are available […], making sure that the latest diffoscope release is in a good fit for the upcoming Debian bookworm freeze.
Reprotest version 0.7.23 was uploaded to both PyPI and Debian unstable, including the following changes:
Holger Levsen improved a lot of documentation […][…][…], tidied the documentation as well […][…], and experimented with a new
Vagrant Cascadian adjusted reprotest to no longer randomise the build locale and use a UTF-8 supported locale instead […] (re. #925879, #1004950), and to also support passing
--vary=locales.locale=LOCALEto specify the locale to vary […].
Separate to this, Vagrant Cascadian started a thread on our mailing list questioning the future development and direction of reprotest.
The Reproducible Builds project detects, dissects and attempts to fix as many currently-unreproducible packages as possible. We endeavour to send all of our patches upstream where appropriate. This month, we wrote a large number of such patches, including:
Bernhard M. Wiedemann:
aiohttp(build fails in the future)
firecracker(hashmap ordering issue)
jhead/gcc(used random temporary directory name)
libhugetlbfs(drop unused unreproducible file)
prosody(generates nondeterministic example SSL certificates)
python-sqlalchemy-migrate(clean files leftover by Sphinx)
tigervnc(random RSA key)
- #1030708 filed against
- #1030714 filed against
- #1030715 filed against
- #1030724 filed against
- #1030727 filed against
- #1031030 filed against
- #1031412 filed against
- #1031829 filed against
- #1032057 filed against
- #1030708 filed against
- #1030270 filed against
- #1030270 filed against
The Reproducible Builds project operates a comprehensive testing framework (available at tests.reproducible-builds.org) in order to check packages and other artifacts for reproducibility. In February, the following changes were made by Holger Levsen:
- Add three new OSUOSL nodes […][…][…] and decommission the
- Change the order of listed Debian architectures to show the 64-bit ones first […].
- Reduce the frequency that the Debian package sets and
dd-listHTML pages update […].
- Sort “Tested suite” consistently (and Debian unstable first) […].
- Update the Jenkins shell monitor script to only query disk statistics every 230min […] and improve the documentation […][…].
Other development work
0.5.11-3 was uploaded by Holger Levsen, fixing a number of issues with the manual page […][…][…].
Bernhard M. Wiedemann published another monthly report about reproducibility within openSUSE.
If you are interested in contributing to the Reproducible Builds project, please visit the Contribute page on our website. You can get in touch with us via: