Reproducible Builds in June 2026 — reproducible-builds.org

Reproducible Builds in June 2026

← View all our monthly reports

Welcome to the June 2026 report from the Reproducible Builds project!

In these reports, we outline the most important things that we have been up to over the past month. As a quick recap about what problem our project intends to solve, whilst anyone may inspect the source code of free software for malicious flaws, almost all software is distributed to end users as pre-compiled binaries. The motivation behind the reproducible builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised or not.

If you are interested in contributing to the project, please visit our Contribute page on our website.

In this month’s report, we cover:

Only installing reproducible packages with repro-threshold

Distribution work

diffoscope development

From our mailing list…

Documentation updates

Patches

Four new scholarly papers

Only installing reproducible packages with repro-threshold

A very interesting demonstration is now available showing how you might configure your Debian system to only install packages that have been reproduced by m/n rebuilders.

This is implemented via a reproduced+https:// APT transport ( a mechanism for communicating between the APT client and its repository source — commonly HTTP):

Every package download is intercepted by repro-threshold, which queries two independent rebuilders for a signed attestation before allowing installation to proceed. [It] is important to note that [an] install will only succeed if all package dependencies are also reproducible.

The demo gives examples of how to quickly experiment with this using a Docker container.

Distribution work

In Debian this month:

The debian-installer package in Debian was uploaded with a substantial reproducibility-related changelog. This means, for the first time, the uploaded version could finally be reproduced.

Various OpenJDK packages were also uploaded to Debian, including the fix for JDK-8385738 (“Javadoc does not produce reproducible output…”) (for example). […][…][…]

The “reason” pages on reproduce.debian.net, such as the one for ppc64el, now feature links labeled with the bug emoji (i.e. 🐛) which links to the categorized issues packages have been tagged with in the reproducible-notes.git repo.

Indeed, 25 reviews of Debian packages were added, 31 were updated and 33 were removed this month adding to our extensive knowledge about identified issues. Two issue types were updated as well. […][…]

The IzzyOnDroid Android APK repository reached its next milestone this month, now covering 2 out of every 3 apps (66.7%) with reproducible builds. Their documentation for debugging and fixing failed builds has steadily grown as well. More clients have picked up showing reproducibility results (e.g. Droid-ify), and Neo Store now can be configured to stick to only reproducible applications. Further, an independent builder has been added to the build farm, increasing the trust level even more as APK builds can have multiple confirmations now.

At the same time, IzzyOnDroid’s rbtlog got several new features. The most outstanding is caching for frequently used resources such as reproducible-apk-tools, command-line tools and NodeJS in order to counter ongoing issues with GitHub availability, while at the same time saving bandwidth and build time. This change also enables some other some smaller enhancements such as being able to configure build timeouts per recipe for those builds running longer than the average, release pattern filtering for update checks or having a field for maintainer notes to shortly summing up e.g. why a reproducible build failed.

Lastly, Bernhard M. Wiedemann posted another openSUSE monthly update for their reproducibility work there.

diffoscope development

diffoscope is our in-depth and content-aware diff utility that can locate and diagnose reproducibility issues. This month, Chris Lamb made the following changes, including preparing and uploading versions 319, 320, 321, 322 and 323 to Debian:

Debian adds an extra Flags: line in the output of ocamlobjinfo, so adjust the test for cross-distribution compatibility. […]

Bump debhelper compatibility level to 14. […]

Fix compatibility with Ocaml 5.4.1. […]

Use --long-form-style arguments when calling apktool in order to support apktool version 3. […]

Support Androguard version 4 and previous versions at the same time. […]

Update copyright years. […]

In addition, Jochen Sprickerhof added better header detection for the Sphinx documentation system […], Michael Daniels fixed the tests when run with zipdetails version 4.006 […] and Zbigniew Jędrzejewski-Szmek added a version of the deprecated os.path.commonprefix method […].

In addition,...