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:

1. Only installing reproducible packages with repro-threshold
2. Distribution work
3. diffoscope development
4. From our mailing list…
5. Documentation updates
6. Patches
7. 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, Vagrant Cascadian updated diffoscope in GNU Guix to version 321 and 323.

Chris Lamb also made the following changes to strip-nondeterminism, our tool to remove specific non-deterministic results from a completed build:

• Skip symlinks when manually called via /usr/bin/strip-nondeterminism. (#1139000)
• Update debian/watch format. […]
• Drop Rules-Requires-Root: no and Priority: optional fields. […]
• Bump Standards-Version to version 4.7.4. […]

From our mailing list…

On our mailing list this month:

• kpcyrd posted to our mailing list regarding the “waves of malware uploads to aur.archlinux.org”. Curiously, “every incident I looked at used npmjs.com for malware delivery”, specifically where the npm package includes an (automatically executed) preinstall script that is an ELF binary.

• kpcyrd also announced the release of debian-repro-status version 0.4.0, a tool written “to give you an approximate idea of how viable it would be to enforce a ‘reproducible packages only’ update policy for the computer system you’ve built”:

  The change updates dependencies to the latest versions, and adds support for multiple -H options, to query results from multiple rebuilderd instances. The results are also now fetched concurrently.

• kpcyrd also reported that, whilst taking a screenshot for the above release, they noticed that the debian:sid container now is 100% reproducible.

• Finally, kpcyrd also created a pull request against the add-determinism package to update the itertools and zip Python dependencies.

Documentation updates

Yet again, there were a number of improvements made to our website this month including:

• Chris Lamb added a reminder re. using the UTC variants of the Javascript Date methods. […]

• Mattia Rizzolo moved OTF to the ‘old’ sponsors list. Thank you for your support!. […]

• kpcyrd updated the Rust documentation to recommend using the --release argument for consistency. […]

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 applicable or possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:

  • cvise
  • efl
  • gettext-runtime/bash
  • hadrian
  • plasma6-keyboard
  • syntax-highlighting

• Chris Lamb:

  • #1139654 filed against node-fuse.js.
  • #1139655 filed against node-egjs-hammerjs.
  • #1139656 filed against node-chartjs-adapter-date-fns.
  • #1139662 filed against mkdocs-include-markdown-plugin.
  • #1139704 filed against lmarbles.
  • #1140240 filed against rocm-docs-core.
  • #1140567 filed against libecoli.
  • #1140688 filed against golang-github-tobischo-gokeepasslib.

• Jochen Sprickerhof:

  • #1139457 filed against c-munipack.
  • #1140365 filed against latex-coffee-stains.
  • #1140366 filed against cxxtest.
  • #1140367 filed against slime.
  • #1140368 filed against spooles.
  • #1140369 filed against sdpb.
  • #1140645 filed against procmail.
  • #1140676 filed against proftpd-dfsg.
  • #1141059 filed against mah-jong.
  • #1141133 filed against dxf2gcode.
  • #1141194 filed against afterstep.
  • #1141195 filed against ledger2beancount.
  • #1141196 filed against ocamlviz.

• Kris Van Hee and Vagrant Cascadian:

  • #1140167 filed against dtrace.

Four new scholarly papers

Kenichiro Muto and Kuniyasu Suzaki of the Institute of Information Security in Yokohama, Japan published an interesting paper this month titled Attestable Build Chain: Enabling Trust in Reproducible Builds (PDF). Their abstract is as follows:

Ensuring trust in software supply chains requires verifying not only artifacts but also the processes that produce them. Although Reproducible Builds (R-B) require rebuilding to validate artifacts, they cannot verify whether the build was executed with the intended toolchain and inputs and may reproduce unintended or compromised builds without detection. We present Attestable Build Chain, a framework for externally verifying build-time execution without rebuilding. Rather than preventing compromise, it provides verifiable, tamper-evident evidence of actual build-time execution, enabling verification of build process integrity from observed file accesses during the build. […]

Julien Malka, Stefano Zacchiroli and Théo Zimmermann published a 50-page report detailing A Decade of Software Reproducibility in the Nix Package Ecosystem:

We find that functional package management enables extremely high rebuildability over time (near-universal ability to reconstitute historical build environments and rebuild software packages), while bitwise reproducibility has steadily improved and reaches a high point in recent years (up to 93% in 2024). Early years show substantially lower bitwise reproducibility, indicating that functional package management alone does not guarantee bitwise-identical outputs, and that the observed high level of bitwise reproducibility is not solely due to the package management approach. Common causes of unreproducibility, both in the rebuildability and bitwise reproducibility dimensions, include management of dates in build and test processes; we quantify their prevalence and other common causes using manual analysis of logs of rebuild failures and automated analysis of diffoscope.

A PDF of their report is available online

Tim Bastin of L3montree GmbH and Jacek Galowicz of Applicative Systems GmbH from DevGuard published a paper detailing How We Built a Sovereign, Reproducible Container Supply Chain for DevGuard:

This paper presents how the DevGuard project rebuilt its OCI container pipeline around reproducible Nix builds and independent dual-platform digest verification. DevGuard images are built hermetically from pinned source revisions, signed with Sigstore/Cosign, and verified through digest comparison across GitHub Actions and sovereign GitLab infrastructure hosted on container.gov.de. We describe the practical integration of reproducible OCI image builds into existing CI/CD workflows and argue that independently reproducible container digests provide a stronger integrity guarantee against build tampering than provenance alone. The paper further discusses remaining trust assumptions and the relevance of sovereign build infrastructure for government and regulated environments.

Finally, Yiseul Choi, Junga Kim, Jun-Ho Hong and Seongmin Kim of the Department of Convergence Security Engineering at the Sungshin Women’s University in Seoul, Korea titled Attestation-based verification of SBOM integrity via consumer-side reproducibility:

Software bills of materials (SBOMs) support supply chain transparency, but they do not prove that a delivered SBOM reproducibly corresponds to its software artifact. Existing signing and provenance mechanisms protect integrity and traceability, yet lack consumer-side reproducible verification. We propose an SBOM integrity verification framework combining procedure disclosure, consumer-side reproduction, authority-generated reference evidence, and digest comparison. A trusted authority records a reference digest, and consumers compare it with locally reproduced and delivered SBOM digests. Experiments on 100 real-world container images show detection of artifact tampering, SBOM substitution, distribution modification, and adaptive tampering beyond signature-based approaches

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

• IRC: #reproducible-builds on irc.oftc.net.

• Mastodon: @reproducible_builds@fosstodon.org

• Mailing list: rb-general@lists.reproducible-builds.org

A new minor release 0.4.28 of RQuantLib arrived on CRAN this evening, has been uploaded to Debian, and is being built for r2u as well.

QuantLib is a rather comprehensice free/open-source library for quantitative finance. RQuantLib connects (some parts of) it to the R environment and language, and has been part of CRAN for nearly twenty-three years (!!) as it was one of the first packages I uploaded to CRAN.

This release of RQuantLib brings a minor update to the calendars for Israel which in QuantLib 1.43 can now use one of three different exchange choices. However, using ‘settlement’ is now deprecated so we adjusted our code. This came up as we had packaged the 1.43-rc version of the (upcoming) 1.43 release a few days ago, and it is now in testing requiring RQuantLib to catch up. Full details from the NEWS file follow as usual.

Changes in RQuantLib version 0.4.28 (2026-07-10)

• Adjust to Israel calendar constructor change in QuantLib 1.43

• Continuous integration uses ccache-with-R action

Courtesy of my CRANberries, there is also a diffstat report for the this release. As always, more detailed information is on the RQuantLib page. Questions, comments etc should go to the rquantlib-devel mailing list. Issue tickets can be filed at the GitHub repo.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

Team Rcpp is excited to share that an brandnew new version 1.1.2 of Rcpp is now on CRAN, has also been uploaded to Debian, and has already built for r2u and r-universe; Windows etc builds at CRAN should follow in due course.

Rcpp has long established itself as the most popular way of enhancing R with C or C++ code. Right now, 3236 packages on CRAN depend on Rcpp for making analytical code go faster and further. On CRAN, 13.4% of all packages depend (directly) on Rcpp, and 61.4% of all compiled packages do. From the cloud mirror of CRAN (which is but a subset of all CRAN downloads), Rcpp has been downloaded 121.6 million times. The two published papers (also included in the package as preprint vignettes) have, respectively, 2263 (JSS, 2011) and 471 (TAS, 2018) citations, while the the book (Springer useR!, 2013) has another 742.

The is the second update in the 1.1.* series which had, among other changes, switched to C++11 as the minimum standard. This release continues as usual with the six-months January-July cycle started with release 1.0.5 in July 2020. Interim snapshots are always available via the r-universe page and repo. We continue to strongly encourage the use of these development released and their testing—we tend to run our systems with them too.

Having said that, we would like to reiterate that we strongly object to the upstream R release and change management which in this 4.6.* cycle made several abrupt changes forcing packages which consume header files to make very abrupt change. Rcpp, just like numerous other CRAN packages demonstrates that API changes can be undertaken responsibly in a managed manner which allows for transition periods followed by possible warning periods, deprecations periods and finally (but only at long last) errors. What happened here is a speed run to the final stage of forced errors. Uncool and irritating for something as widely used as R. This forced us to make an interim release 1.1.1-1.1 even though we have of course had a policy of always keeping properly tested, installable, and error-free releases candidate version in the main repository branch and hence available via R-universe tested packages for all relevant platforms, and even via binaries for most (including Ubuntu LTS). It would be nice if R Core found a way to take advantage of this. Maybe development cycles, running apart for a year as they do for R, should also include selected packages.

Once again I am not attempting to summarize the different changes. The full list follows below and details all these changes, their respective PRs and, if applicable, issue tickets. Big thanks from all of us to all contributors!

Changes in Rcpp release version 1.1.2 (2026-07-01)

• Changes in Rcpp API:

  • Use of execinfo.h is again conditional to avoid build complexity (Dirk in #1445 addressing #1442)

  • An internal state component for Datetime is now int (Dirk in #1448 and #1449 fixing #1447)

  • Three new (in R 4.6.0) attribute accessors are used conditionally (Dirk in #1450 closing #1432)

  • An UBSAN error in the Sugar-based NA comparison has been corrected (Iñaki in #1453 fixing #1452)

  • Treatment of Inf outside of integer range in Sugar function has been corrected (Iñaki in #1458 fixing #1455)

  • Integer overflow protection has been added for sugar functions (Iñaki in #1457 fixing #1454)

  • The parent environment is now accessed via R_ParentEnv (Dirk in #1460 fixing #1459)

  • Change to returning dataptr again for better handling of empty vectors (Iñaki in #1462 fixing #1461)

  • Undefined behavior errors in use of ListOf proxies have been addressed (Iñaki in #1464 fixing #1463)

  • Under newer R version, R_UnboundValue is no longer used (Iñaki in #1466 fixing #1465)

  • New R API access point R_getRegisteredNamespace() is used with current R versions (Dirk in #1469 fixing #1468)

  • The Nullable::as() exporter now uses an explicit cast to the templated type (Dirk in #1471 fixing #1470)

  • A memory leak in the variadic Rcpp::warning() template has been fixed (Kevin in #1475 fixing #1474)

  • The Nullable::operatorT() has been added as a 'opt-out' (Dirk in #1477 with coordination in #1472)

  • Add templated integer-index overload for operator[] on small systems such as WASM (Jeroen Ooms in #1482)

  • The attribute accessors in AttributeProxyPolicy no longer rely on get__() (Kevin in #1484 fixing #1483)

• Changes in Rcpp Documentation:

  • Reference in the bibliography used by the package vignettes have been updated.

• Changes in Rcpp Deployment:

  • Excute permissions are set consistently on scripts with shebangs (Mattias Ellert in #1467)

  • R 4.5.* has been added to the CI matrix (Dirk in #1476)

  • Three nag messages issued when obsolete build flag accessors are used now show Rcpp::: (Dirk in #1480 fixing #1456)

  • Reference GitHub Actions have been updated to their current versions (Dirk in #1481)

• Non-release Changes:

  • A non-release hotfix 1.1.1-1 used by CRAN accommodates breaking changes to the API in R 4.6.0. It would be nice to have the same level of release management in R itself that CRAN expects from us.

Thanks to my CRANberries, you can also look at a diff to the previous interim release along with pre-releases 1.1.1-1 and 1.1.1-1.1 that were needed because R-devel once again sudden decided to move fast and break things. Not our doing. And there also should not have been a need to two such uploads but it was amateur hour all around.

Questions, comments etc should go to the GitHub discussion or issue section, or the Rcpp list. Bugs reports are welcome at the GitHub issue tracker as well. GitHub offers decent search for issue, pull requests and discussions; as many topics have been covered it is worth checking as well.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

I used to ice skate as a teenager but I stopped at University. I tried to pick it back up in 2024 but had to stop when I got ill. I restarted in 2025, initially with a weekly skate session but last month I started group hockey skate lessons.

I've been skating in a pair of Bauer¹ Nexus N77s that I bought 7 years ago on a work trip to Toronto. These did a great job of getting me back into the hobby for 6 years but recently I felt it was time to step up to a better quality pair. Despite being a size down from my shoe size, the Nexuses are too large: I had been compensating with thick socks but still struggling to get the boots tight enough. I'd have to wear gloves to lace up because I'd cut my hands pulling the laces otherwise.

After too long researching/deliberating/kvetching (very much on trend for me) I upgraded to Bauer Vapor Fly30s another half-size down (and nearly ten times as much). The fit is much better, in almost every respect. They actually go on easier and I don't have to tear my hands tightening the laces. They feel like a natural extension of my feet. I seem to be using a different set of muscles to skate, so the first few sessions were very fatiguing, but that settled. The Vapor line is speed-oriented, which I thought would fit my skate style best.

I have unfortunately gained a common problem: arch pain. More precisely, my navicular bone seems to be quite prominent², and that part is pressing uncomfortably into the boot. Boots typically take a few sessions to break in, but after 7-8 sessions the pain was getting to the stage that I couldn't skate for a full session without being in agony.

The last time I skated I tried to throw everything at the problem: I'd had the skates baked³; bought some orthotic insoles; then some "Bunga" pads over the sore bit and an attempt to more loosely tie the laces over the affected area. I tried a ten minute skate, and it seemed a bit better.

I then tried experimentally to swap back to my old skates, and I felt like Bambi: I just couldn't do it! They didn't press on the navicular, and they're softer so you can compensate for the size with tight lacing, but I had no confidence in them, I couldn't lean into the turns. They just felt weird. I realised there's no way back.

I switched back to the fly30s, adjusted the bunga pad positioning, tweaked the lacing and went back on for about 40 minutes. It went well: the rink was quiet, it was cool whilst we had a heat wave outside, so I worked up a sweat. By the end there was some discomfort, but not too much, and I think partly the area is currently sensitive so just about anything will cause discomfort. Fingers (or toes) crossed that I've mitigated the problem! If not, it might be time to try a punch out.