Reproducible Builds in July 2025
Chris Lamb
chris at reproducible-builds.org
Wed Aug 6 21:13:14 UTC 2025
--------------------------------------------------------------------
o
⬋ ⬊ July 2025 in Reproducible Builds
o o
⬊ ⬋ https://reproducible-builds.org/reports/2025-07/
o
--------------------------------------------------------------------
Welcome to the seventh report from the Reproducible Builds [0]
project in 2025. Our monthly reports outline what we've been
up to over the past month, and highlight items of news from
elsewhere in the increasingly-important area of software
supply-chain security.
If you are interested in contributing to the Reproducible
Builds project, please see the Contribute [1] page on our
website.
[0] https://reproducible-builds.org/
[1] https://reproducible-builds.org/contribute/
§
In this report:
* Reproducible Builds Summit 2025
* Reproducible Builds an official goal for SUSE Enterprise Linux
* Reproducible Builds at FOSSY 2025
* New OSS Rebuild project from Google
* New extension of Python setuptools to support reproducible builds
* "diffoscope"
* New library to patch system functions for reproducibility
* "Independently Reproducible Git Bundles"
* Website updates
* Distribution work
* Reproducibility testing framework
* Upstream patches
§
Reproducible Builds Summit 2025 [2]
-----------------------------------
We are extremely pleased to announce the upcoming Reproducible
Builds Summit [3], set to take place from October 28th — 30th
2025 in Vienna, Austria!
We are thrilled to host the eighth edition of this exciting
event, following the success of previous summits in various
iconic locations around the world, including Venice,
Marrakesh, Paris, Berlin, Hamburg and Athens. Our summits are
a unique gathering that brings together attendees from diverse
projects, united by a shared vision of advancing the
Reproducible Builds effort.
During this enriching event, participants will have the
opportunity to engage in discussions, establish connections
and exchange ideas to drive progress in this vital field. Our
aim is to create an inclusive space that fosters
collaboration, innovation and problem-solving.
If you're interesting in joining us this year, please make
sure to read the event page [4] which has more details about
the event and location. Registration is open until 20th
September 2025, and we are very much looking forward to seeing
many readers of these reports there!
[2] https://reproducible-builds.org/events/vienna2025/
[3] https://reproducible-builds.org/events/vienna2025/
[4] https://reproducible-builds.org/events/vienna2025/
§
Reproducible Builds an official goal for SUSE Enterprise Linux [5]
------------------------------------------------------------------
On our mailing list this month [6], Bernhard M. Wiedemann
revealed the big news that reproducibility is now an official
goal for SUSE Linux Enterprise Server (SLES) 16 [7]:
> [Everything] changed earlier this year when
> reproducible-builds for SLES-16 became an official goal for
> the product. More people are talking about digital
> sovereignty and supply-chain security now. […] Today, only 9
> of 3319 (source) packages have significant problems left
> (plus 7 with pending fixes), so 99.5% of packages have
> reproducible builds.
[5] https://lists.reproducible-builds.org/pipermail/rb-general/2025-July/003846.html
[6] https://lists.reproducible-builds.org/listinfo/rb-general
[7] https://lists.reproducible-builds.org/pipermail/rb-general/2025-July/003846.html
§
Reproducible Builds at FOSSY 2025 [8]
-------------------------------------
On Saturday 2nd August, Vagrant Cascadian and Chris Lamb
presented at this year's FOSSY 2025 [9]. Their talk, titled
"Never Mind the Checkboxes, Here's Reproducible Builds!" [10],
was introduced as follows:
> There are numerous policy compliance and regulatory
> processes being developed that target software development,
> but do they solve actual problems? Does it improve the
> quality of software? Do Software Bill of Materials (SBOMs)
> actually give you the information necessary to verify how a
> given software artifact was built? What is the goal of all
> these compliance checklists anyways… or more importantly,
> what *should* the goals be? If a software object is signed,
> who should be trusted to sign it, and can they be trusted
> forever?
Hosted by the Software Freedom Conservancy [11] and taking
place in Portland, Oregon, USA, FOSSY aims to be a
community-focused event: "Whether you are a long time
contributing member of a free software project, a recent
graduate of a coding bootcamp or university, or just have an
interest in the possibilities that free and open source
software bring, FOSSY will have something for you". More
information on the event is available on the FOSSY 2025
website [12], including the full programme schedule [13].
Vagrant and Chris also staffed a table, where they will be
available to answer any questions about Reproducible Builds
and discuss collaborations with other projects.
[8] https://2025.fossy.us/schedule/presentation/327/
[9] https://2025.fossy.us/
[10] https://2025.fossy.us/schedule/presentation/327/
[11] https://sfconservancy.org/
[12] https://2025.fossy.us/about/
[13] https://2025.fossy.us/schedule/
§
New OSS Rebuild project from Google [14]
----------------------------------------
The Google Open Source Security Team (GOSST) published an
article this month announcing OSS Rebuild [15], "a new project
to strengthen trust in open source package ecosystems by
reproducing upstream artifacts." As the post [16] itself
documents, the new project comprises four facets:
> * Automation to derive declarative build definitions for
> existing PyPI (Python), npm (JS/TS), and Crates.io (Rust)
> packages.
>
> * SLSA [17] Provenance for thousands of packages across our
> supported ecosystems, meeting SLSA Build Level 3
> requirements with no publisher intervention.
>
> * Build observability and verification tools that security
> teams can integrate into their existing vulnerability
> management workflows.
>
> * Infrastructure definitions to allow organizations to
> easily run their own instances of OSS Rebuild to rebuild,
> generate, sign, and distribute provenance.
One difference with most projects that aim for bit-for-bit
reproducibility, OSS Rebuild aims for a kind of "semantic"
reproducibility:
> Through automation and heuristics, we determine a
> prospective build definition for a target package and
> rebuild it. We semantically compare the result with the
> existing upstream artifact, normalizing each one to remove
> instabilities that cause bit-for-bit comparisons to fail
> (e.g. archive compression).
The extensive post includes examples about how to access OSS
Rebuild attestations using the Go-based command-line
interface.
[14] https://security.googleblog.com/2025/07/introducing-oss-rebuild-open-source.html
[15] https://security.googleblog.com/2025/07/introducing-oss-rebuild-open-source.html
[16] https://security.googleblog.com/2025/07/introducing-oss-rebuild-open-source.html
[17] https://slsa.dev/
§
New extension of Python setuptools to support reproducible builds
-----------------------------------------------------------------
Wim Jeantine-Glenn has written a PEP 517 Build backend [18] in
order to enable reproducible builds when building Python
projects that use setuptools [19].
Called setuptools-reproducible [20], the project's README file
[21] contains the following:
> Setuptools can create reproducible wheel archives (.whl) by
> setting SOURCE_DATE_EPOCH at build time, but setting the env
> var is insufficient for creating reproducible sdists
> (.tar.gz). setuptools-reproducible [therefore] wraps the
> hooks build_sdist build_wheel with some modifications to
> make reproducible builds by default.
[18] https://peps.python.org/pep-0517/#build-backend-interface
[19] https://setuptools.pypa.io/en/latest/
[20] https://pypi.org/project/setuptools-reproducible/
[21] https://github.com/wimglenn/setuptools-reproducible/blob/main/README.md
§
diffoscope
----------
diffoscope [23] 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 301, 302 and 303 to Debian:
* Improvements:
* Use Difference.from_operation in an attempt to pipeline the
output of the extract-vmlinux script, potentially avoiding it all
in memory. [24]
* Memoize a number of calls to --version, saving a very large
number of external subprocess calls.
[23] https://diffoscope.org
[24] https://salsa.debian.org/reproducible-builds/diffoscope/commit/c7283818
* Bug fixes:
* Don't check for PyPDF version 3 specifically, check for versions
greater than 3. [25]
* Ensure that Java class files are named .class on the filesystem
before passing them to javap(1). [26]
* Mask stderr from extract-vmlinux script. [27][28]
* Avoid spurious differences in h5dump output caused by exposure of
absolute internal extraction paths. (#1108690 [29])
[25] https://salsa.debian.org/reproducible-builds/diffoscope/commit/9ec7aad21d7a45069a3dddd4bcee476fe1dff1ae
[26] https://salsa.debian.org/reproducible-builds/diffoscope/commit/9ec7aad2
[27] https://salsa.debian.org/reproducible-builds/diffoscope/commit/35b0dbb4
[28] https://salsa.debian.org/reproducible-builds/diffoscope/commit/510945b7
[29] https://bugs.debian.org/1108690
* Misc:
* Use our_check_output in the ODT comparator. [30]
* Update copyright years. [31]
[30] https://salsa.debian.org/reproducible-builds/diffoscope/commit/90046c65
[31] https://salsa.debian.org/reproducible-builds/diffoscope/commit/acedd232
In addition:
* Siva Mahadevan made a change to use the --print-armap long option
when calling nm(1) for wider compatibility. [32]
* Vagrant Diffoscope updated diffoscope in GNU Guix to 300 [33] [34],
301 [35] [36], 302 [37] and fixed the execute bit on the extract-
vmlinux script [38] [39].
[32] https://salsa.debian.org/reproducible-builds/diffoscope/commit/ffa385d3
[33] https://codeberg.org/guix/guix/commit/dd7e39ccfdd23a388dfa6b7665de466691bc6cda
[34] https://codeberg.org/guix/guix/pulls/886
[35] https://codeberg.org/guix/guix/commit/02a94e80243b1ed1f84fc3cce2554f2d06fd1664
[36] https://codeberg.org/guix/guix/pulls/1240
[37] https://codeberg.org/guix/guix/pulls/1576
[38] https://codeberg.org/guix/guix/commit/4c4451b9232ff22eef8bb2f8b512fd8a5e6b766c
[39] https://codeberg.org/guix/guix/pulls/1307
Lastly, Chris Lamb added a tmpfs to try.diffoscope.org [40] so
that diffoscope has a non-trivial temporary area to unpack
archives, etc. [41]
[40] https://try.diffoscope.org/
[41] https://salsa.debian.org/reproducible-builds/try.diffoscope.org/commit/514637a
Elsewhere in our tooling, however, reprotest [42] is our tool
for building the same source code twice in different
environments and then checking the binaries produced by each
build for any differences. This month, reprotest version
0.7.30 was uploaded to Debian unstable [43] by Holger Levsen,
chiefly including a change by Rebecca N. Palmer to not call
sudo with the -h flag in order to fix Debian bug #1108550 [44]. [45]
[42] https://salsa.debian.org/reproducible-builds/reprotest
[43] https://tracker.debian.org/pkg/reprotest
[44] https://bugs.debian.org/1108550
[45] https://salsa.debian.org/reproducible-builds/reprotest/commit/513b9a5
§
New library to patch system functions for reproducibility
---------------------------------------------------------
Nicolas Graves [46] has written and published libfate [47], a
simple collection of tiny libraries to patch system functions
deterministically using LD_PRELOAD. According to the project's
README [48]:
> libfate provides deterministic replacements for common non-
> deterministic system functions that can break reproducible
> builds. Instead of relying on complex build systems or apps
> or extensive patching, libfate uses the LD_PRELOAD trick to
> intercept system calls and return fixed, predictable values.
Describing why he wrote it, Nicolas writes:
> I originally used the OpenSUSE dettrace [49] approach to
> make Emacs reproducible in Guix. But when Guix switch to
> GCC at 14, dettrace stopped working as expected. dettrace is a
> complex piece of software, my need was much less heavy: I
> don't need to systematically patch all sources of
> nondeterminism, just the ones that make a process/binary
> unreproducible in a container/chroot.
[46] https://git.sr.ht/~ngraves
[47] https://github.com/nicolas-graves/libfate
[48] https://github.com/nicolas-graves/libfate/blob/master/README.md
[49] https://github.com/dettrace/dettrace
§
"Independently Reproducible Git Bundles"
----------------------------------------
Simon Josefsson [51] has published another interesting article
this month. Titled "Independently Reproducible Git Bundles"
[52], the blog post describes the advantages of why you might
a reproducible bundle, and the pitfalls that can arise when
trying to create them:
> One desirable property is that someone else should be able
> to reproduce the same git bundle, and not only that a single
> individual is able to reproduce things on one machine. It
> surprised me to see that when I ran the same set of commands
> on a different machine (started from a fresh git clone), I
> got a different checksum. The different checksums occurred
> even when nothing had been committed on the server side
> between the two runs.
[51] https://blog.josefsson.org/
[52] https://blog.josefsson.org/2025/07/31/independently-reproducible-git-bundles/
§
Website updates
---------------
Once again, there were a number of improvements made to our website this
month including:
* Bernhard M. Wiedemann added an entry related to R-B-OS [53] on the
"History" [54] page. [55]
[53] https://news.opensuse.org/2025/02/18/rbos-project-hits-milestone/
[54] https://reproducible-builds.org/docs/history/
[55] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/3d9b305f
* Chris Lamb:
* Replaced "rbtlog run by Fay" by "rbtlog run by Benl" on the "Who
is involved" [56] page. [57]
* Added a new, centered version of the RB logo. [58]
[56] https://reproducible-builds.org/who/projects/
[57] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/38403846
[58] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/a97b47a9
* Holger Levsen:
* Added and worked on the page for the Vienna 2025 summit
[59]. [60][61]
* Add Jarl Gullberg to the "Who is involved?" [62] page. [63]
* Add a talk from the recent MiniDebConf in Hamburg [64] to our
database of talks and presentations [65]. [66]
[59] https://reproducible-builds.org/events/vienna2025/
[60] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/db6a0059
[61] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/b69089de
[62] https://reproducible-builds.org/who/people/
[63] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/3802fc00
[64] https://hamburg2025.mini.debconf.org/
[65] https://reproducible-builds.org/resources/
[66] https://salsa.debian.org/reproducible-builds/reproducible-website/commit/f13c6636
* Julien Cristau fixed a link to the diffoci repository [67] on the
*Tools* [68]
[67] https://github.com/reproducible-containers/diffoci
[68] https://reproducible-builds.org/tools/
§
Distribution work
-----------------
In Debian [69] this month:
* 5 reviews of Debian packages were added, 4 were updated and
2 were removed this month adding to our ever-increasing
knowledge about identified issues [70].
* The release notes for the upcoming Debian Trixie release
feature the following paragraph related to Reproducible
Builds, thanks to the collaboration of Justin B Rye, Chris
Hofstaedtler, Vagrant Cascadian and Holger Levsen [71]:
> Debian contributors have made significant progress
> toward ensuring package builds produce byte-for-byte
> reproducible results. You can check the status for
> packages installed on your system using the new package
> debian-repro-status, or visit reproduce.debian.net [72]
> for Debian’s overall statistics for trixie and later.
> You can contribute to these efforts by joining
> #debian-reproducible on IRC to discuss fixes, or verify
> the statistics by installing the new rebuilderd package
> and setting up your own instance.
[69] https://debian.org/
[70] https://tests.reproducible-builds.org/debian/index_issues.html
[71] https://salsa.debian.org/ddp-team/release-notes/-/merge_requests/294
[72] https://reproduce.debian.net/
The IzzyOnDroid Android APK repository made further progress
in July, crossing the 50% reproducibility threshold [74] —
congratulations! Furthermore, a new release of the Neo Store
[75] was released, which exposes the reproducible status
directly next to the version of each app [76].
[74] https://apt.izzysoft.de/fdroid
[75] https://apt.izzysoft.de/packages/com.machiav3lli.fdroid
[76] https://floss.social/@IzzyOnDroid/114954919343237344
In GNU Guix [77], a series of patches intended to fix the
reproducibility for the Mono programming language [78] was
merged, fixing reproducibility in Mono versions 1.9 [79], 2.4
[80] and 2.6 [81].
[77] https://guix.gnu.org/
[78] https://codeberg.org/guix/guix/pulls/507
[79] https://codeberg.org/guix/guix/commit/69d8d749e14d5c3c17628946f0b523529d041680
[80] https://codeberg.org/guix/guix/commit/f0b8657c429dadeee7dda7bb1a071bac41f3e354
[81] https://codeberg.org/guix/guix/commit/52df09e31bc342c18369844991b2e5f70d2c36a4
Lastly, in addition to the news that openSUSE [82] Enterprise
Linux has an official release goal of reproduciblit, Bernhard M.
Wiedemann posted another monthly update [83] for their work there.
[82] https://www.opensuse.org/
[83] https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/thread/NJNQL5ZX7E3QPYAO5WXEMOY4YGYB5GZ6/
§
Reproducibility testing framework
---------------------------------
The Reproducible Builds project operates a comprehensive
testing framework running primarily at
tests.reproducible-builds.org [84] in order to check packages
and other artifacts for reproducibility. In June, however, a
number of changes were made by Holger Levsen, including:
* Switch the URL for the Tails [85] package set. [86]
* Make the dsa-check-packages output more useful. [87]
* Setup the ppc64el architecture again, has it has returned —
this time with a 2.7 GiB database instead of 72 GiB. [88]
[84] https://tests.reproducible-builds.org
[85] https://tails.net/
[86] https://salsa.debian.org/qa/jenkins.debian.net/commit/2c8e97a8d
[87] https://salsa.debian.org/qa/jenkins.debian.net/commit/2e1412c30
[88] https://salsa.debian.org/qa/jenkins.debian.net/commit/5d3cfe792
In addition, Jochen Sprickerhof improved the reproducibility
statistics generation:
* Enable caching of statistics. [89][90][91]
* Add some common non-reproducible patterns. [92]
* Change output to directory. [93]
* Add a page sorted by diffoscope size. [94][95]
* Switch to Python's argparse module and separate output(). [96]
[89] https://salsa.debian.org/qa/jenkins.debian.net/commit/ec7825b98
[90] https://salsa.debian.org/qa/jenkins.debian.net/commit/76d6da2c2
[91] https://salsa.debian.org/qa/jenkins.debian.net/commit/b90162104
[92] https://salsa.debian.org/qa/jenkins.debian.net/commit/59c30493d
[93] https://salsa.debian.org/qa/jenkins.debian.net/commit/3f8d857ff
[94] https://salsa.debian.org/qa/jenkins.debian.net/commit/c8b1bac24
[95] https://salsa.debian.org/qa/jenkins.debian.net/commit/7deb59d83
[96] https://salsa.debian.org/qa/jenkins.debian.net/commit/52af44ce3
Holger also submitted a number of Debian bugs against rebuilderd
and rebuilderd-worker:
* Config files and scripts for a simple one-machine setup. [97][98]
* Create a rebuilderd user. [99]
* Create rebuilderd-worker user with sbuild. [100]
[97] https://bugs.debian.org/1109459
[98] https://bugs.debian.org/1110037
[99] https://bugs.debian.org/1110036
[100] https://bugs.debian.org/1110038
Lastly, Mattia Rizzolo added a scheduled job to renew some SSL
certificates [101] and Vagrant Cascadian performed some node
maintenance [102][103].
[101] https://salsa.debian.org/qa/jenkins.debian.net/commit/ed312001f
[102] https://salsa.debian.org/qa/jenkins.debian.net/commit/29aa71bf2
[103] https://salsa.debian.org/qa/jenkins.debian.net/commit/f83ef9b59
§
Upstream patches
----------------
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:
* dpdk [104]
* HTTP-CookieJar [105]
* ibus-libzhuyin [106]
* java-21-openjdk [107]
* kea [108]
* libcamera [109]
* libpinyin [110]
* libsemigroups [111]
* llvm [112], llvm20 [113] , llvm20 [114], llvm19 [115], llvm15
[116], llvm17 [117] (and all backports to llvm7-19)
* mumble [118]
* python-Babel/pympress [119]
* python-numpy [120]
* python-numpy [121]
* python-paho-mqtt [122]
* python-rencode [123]
* rabbitmq-server [124]
* rage [125]
* re-flex [126]
* shadow-rs [127]
[104] https://build.opensuse.org/request/show/1296685
[105] https://github.com/dagolden/HTTP-CookieJar/pull/16
[106] https://build.opensuse.org/request/show/1296344
[107] https://build.opensuse.org/request/show/1293272
[108] https://src.opensuse.org/dhcp/kea/pulls/9
[109] https://src.opensuse.org/jengelh/libcamera/pulls/6
[110] https://build.opensuse.org/request/show/1296340
[111] https://github.com/libsemigroups/libsemigroups/issues/767
[112] https://github.com/llvm/llvm-project/pull/146822
[113] https://build.opensuse.org/request/show/1290617
[114] https://build.opensuse.org/request/show/1293268
[115] https://build.opensuse.org/request/show/1292247
[116] https://build.opensuse.org/request/show/1292274
[117] https://build.opensuse.org/request/show/1292273
[118] https://github.com/mumble-voip/mumble/pull/6872
[119] https://build.opensuse.org/request/show/1295211
[120] https://build.opensuse.org/request/show/1296687
[121] https://github.com/numpy/SVML/pull/7
[122] https://build.opensuse.org/request/show/1290153
[123] https://bugzilla.opensuse.org/show_bug.cgi?id=1246916
[124] https://bugzilla.opensuse.org/show_bug.cgi?id=1245558
[125] https://github.com/str4d/rage/pull/580
[126] https://bugzilla.opensuse.org/show_bug.cgi?id=1246164
[127] https://github.com/baoyachi/shadow-rs/pull/235
* Chris Lamb:
* #1109484 [128] filed against rust-microformats [129]
* #1109731 [130] filed against piglit [131]
[128] https://bugs.debian.org/1109484
[129] https://tracker.debian.org/pkg/rust-microformats
[130] https://bugs.debian.org/1109731
[131] https://tracker.debian.org/pkg/piglit
* Rafał Mikrut:
* cargo-i18n [132]
[132] https://github.com/kellpossible/cargo-i18n/pull/151
* Robin Candau:
* netdata [133]
[133] https://github.com/netdata/netdata/pull/20714
There were a number of other patches from openSUSE [134] developers:
* BCI-dockerfile-generator [135] (Dirk Mueller)
* agama [136] (Imobach Gonzalez Sosa)
* emacs [137] (Werner Fink)
* firecracker [138] (Andrea Manzini)
* maven-archiver [139] (Fridrich Strba)
* moditect [140] (Fridrich Strba)
* obs-build [141] (Adrian Schroeter)
* ovmf [142] (Richard Lyu)
* python-rdflib [143] (Daniel Garcia)
* python313:doc [144] (Daniel Garcia)
[134] https://www.opensuse.org/
[135] https://github.com/SUSE/BCI-dockerfile-generator/pull/2749
[136] https://github.com/agama-project/agama/pull/2528
[137] https://build.opensuse.org/request/show/1292097
[138] https://github.com/firecracker-microvm/firecracker/pull/5298
[139] https://github.com/apache/maven-archiver/pull/273
[140] https://github.com/moditect/moditect/pull/263
[141] https://github.com/openSUSE/obs-build/commit/e3812b225f8b6fb66301c8dbee9e5bf242939f8a
[142] https://build.opensuse.org/request/show/1290620
[143] https://build.opensuse.org/request/show/1291184
[144] https://github.com/python/cpython/pull/136165
§
And finally, if you are interested in contributing to the
Reproducible Builds project, please visit the "Contribute"
[145] page on our website. However, you can get in touch with
us via:
* IRC: #reproducible-builds on irc.oftc.net.
* Mastodon: @reproducible_builds at fosstodon.org [146]
* Mailing list: rb-general at lists.reproducible-builds.org [147]
[145] https://reproducible-builds.org/contribute/
[146] https://fosstodon.org/@reproducible_builds
[147] https://lists.reproducible-builds.org/listinfo/rb-general
--
o
⬋ ⬊
o o reproducible-builds.org 💠
⬊ ⬋
o
More information about the rb-general
mailing list