Reproducible Builds in December 2022

← View all our monthly reports


Welcome to the December 2022 report from the Reproducible Builds project.

We are extremely pleased to announce that the dates for the Reproducible Builds Summit in 2023 have been announced in 2022 already:

  • When: October 31st, November 1st, November 2nd 2023.
  • Where: Dock Europe, Hamburg, Germany.

We plan to spend three days continuing to the grow of the Reproducible Builds effort. As in previous events, the exact content of the meeting will be shaped by the participants. And, as mentioned in Holger Levsen’s post to our mailing list, the dates have been booked and confirmed with the venue, so if you are considering attending, please reserve these dates in your calendar today.

Rémy Grünblatt, an associate professor in the Télécom Sud-Paris engineering school wrote up his “pain points” of using Nix and NixOS. Although some of the points do not touch on reproducible builds, Rémy touches on problems he has encountered with the different kinds of reproducibility that these distributions appear to promise including configuration files affecting the behaviour of systems, the fragility of upstream sources as well as the conventional idea of binary reproducibility.

Morten Linderud reported that he is quietly optimistic that if Go programming language resolves all of its issues with reproducible builds (tracking issue) then the Go binaries distributed from Google and by Arch Linux may be bit-for-bit identical. “It’s just a bit early to sorta figure out what roadblocks there are. [But] Go bootstraps itself every build, so in theory I think it should be possible.”

On December 15th, Holger Levsen published an in-depth interview he performed with David A. Wheeler on supply-chain security and reproducible builds, but it also touches on the biggest challenges in computing as well.

This is part of a larger series of posts featuring the projects, companies and individuals who support the Reproducible Builds project. Other instalments include an article featuring the Civil Infrastructure Platform project and followed this up with a post about the Ford Foundation as well as a recent ones about ARDC, the Google Open Source Security Team (GOSST), Jan Nieuwenhuizen on Bootstrappable Builds, GNU Mes and GNU Guix and Hans-Christoph Steiner of the F-Droid project.

A number of changes were made to the Reproducible Builds website and documentation this month, including FC Stegerman adding an F-Droid/apksigcopier example to our embedded signatures page […], Holger Levsen making a large number of changes related to the 2022 summit in Venice as well as 2023’s summit in Hamburg […][…][…][…] and Simon Butler updated our publications page […][…].

On our mailing list this month, James Addison asked a question about whether there has been any effort to trace the files used by a build system in order to identify the corresponding build-dependency packages. […] In addition, Bernhard M. Wiedemann then posed a thought-provoking question asking “How to talk to skeptics?”, which was occasioned by a colleague who had published a blog post in May 2021 skeptical of reproducible builds. The thread generated a number of replies.

Android news

obfusk (FC Stegerman) performed a thought-provoking review of tools designed to determine the difference between two different .apk files shipped by a number of free-software instant messenger applications.

These scripts are often necessary in the Android/APK ecosystem due to these files containing embedded signatures so the conventional bit-for-bit comparison cannot be used. After detailing a litany of issues with these tools, they come to the conclusion that:

It’s quite possible these messengers actually have reproducible builds, but the verification scripts they use don’t actually allow us to verify whether they do.

This reflects the consensus view within the Reproducible Builds project: pursuing a situation in language or package ecosystems where binaries are bit-for-bit identical (over requiring a bespoke ecosystem-specific tool) is not a luxury demanded by purist engineers, but rather the only practical way to demonstrate reproducibility. obfusk also announced the first release of their own set of tools on our mailing list.

Related to this, obfusk also posted to an issue filed against Mastodon regarding the difficulties of creating bit-by-bit identical APKs, especially with respect to copying v2/v3 APK signatures created by different tools; they also reported that some APK ordering differences were not caused by building on macOS after all, but by using Android Studio […] and that F-Droid added 16 more apps published with Reproducible Builds in December.

Debian

As mentioned in last months report, Vagrant Cascadian has been organising a series of online sprints in order to ‘clear the huge backlog of reproducible builds patches submitted’ by performing NMUs (Non-Maintainer Uploads).

During December, meetings were held on the 1st, 8th, 15th, 22nd and 29th, resulting in a large number of uploads and bugs being addressed:

The next sprint is due to take place this coming Tuesday, January 10th at 16:00 UTC.

Upstream patches

The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. This month, we wrote a large number of such patches, including:

Testing framework

The Reproducible Builds project operates a comprehensive testing framework at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In October, the following changes were made by Holger Levsen:

  • The osuosl167 machine is no longer a openqa-worker node anymore. […][…]
  • Detect problems with APT repository signatures […] and update a repository signing key […].
  • reproducible Debian builtin-pho: improve job output. […]
  • Only install the foot-terminfo package on Debian systems. […]

In addition, Mattia Rizzolo added support for the version of diffoscope in Debian stretch which doesn’t support the --timeout flag. […][…]

diffoscope

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 made the following changes to diffoscope, including preparing and uploading versions 228, 229 and 230 to Debian:

  • Fix compatibility with file(1) version 5.43, with thanks to Christoph Biedl. […]
  • Skip the test_html.py::test_diff test if html2text is not installed. (#1026034)
  • Update copyright years. […]

In addition, Jelle van der Waa added support for Berkeley DB version 6. […]

Orthogonal to this, Holger Levsen bumped the Debian Standards-Version on all of our packages, including diffoscope […], strip-nondeterminism […], disorderfs […] and reprotest […].

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. You can get in touch with us via:



← View all our monthly reports

Follow us on Twitter @ReproBuilds, Mastodon @reproducible_builds@fosstodon.org & Reddit and please consider making a donation. • Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. • Patches for this website welcome via our Git repository (instructions) or via our mailing list. • Full contact info