# reproducible builds Published articles for reproducible builds. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Supporter spotlight: Jochen Sprickerhof on reproducible builds DevFeed: [Supporter spotlight: Jochen Sprickerhof on reproducible builds]() Original publisher: [Read original article]() Published: 2026-09-15T03:54:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [Open Source](), [Debian](), [Programming](), [F-Droid](), [Robotics](), [Point cloud]() Tags: [debian](), [open-source](), [org](), [programming](), [reproducible-builds](), [robotics]() ### AI overview An interview with Jochen Sprickerhof, a freelance programmer and Reproducible Builds core team member, covering his work on Debian, F-Droid, software projects, and bit-for-bit reproduction of Debian packages. ### Source excerpt The Reproducible Builds project relies on several projects, supporters and sponsors for financial support, but they are also valued as ambassadors who spread the word about our project and the work that we do. This is the ninth installment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by featuring the Civil Infrastructure Platform project, and followed this up with a post about the Ford Foundation as well as recent ones about ARDC, the Google Open Source Security Team (GOSST), Bootstrappable Builds, the F-Droid project, David A. Wheeler, Simon Butler and Kees Cook. Today, however, we will be talking with Jochen Sprickerhof, one of the newer members of the Reproducible Builds project core team. Vagrant Cascadian: Could you tell me a bit about yourself? What sort of things do you work on? Jochen Sprickerhof: I am a freelance programmer working on Open Source. Mainly doing Debian, F-Droid and some smaller software projects. In general I made it a habit to look into every software I use and try to fix bugs or add features I need. In Debian, I maintain about 180 packages with topics covering home banking, build systems and robotics. Most of my time, I currently work on reproduce.debian.net, where we try to bit-for-bit reproduce the packages distributed by Debian. Vagrant: Could you describe the path that lead you to working on reproducible builds? Jochen: I started my Debian journey as a teenager, converting my school to Debian and serving as its system administrator for 13 years. After studying Applied System Science, I joined the university's robotics labs, where I worked on the Robot Operating System (ROS) and the Point Cloud Library (PCL). In the end, I enjoyed programming more than writing papers, so I eventually left academia for a robotics startup. Some years ago, I realized that the open source work I was doing in my spare time was actually the work I cared most about. Nowadays I ## The Real Python Podcast - Episode #311: Django Developers Survey Results & Reproducible Python Builds DevFeed: [The Real Python Podcast - Episode #311: Django Developers Survey Results & Reproducible Python Builds]() Original publisher: [Read original article]() Author: Real Python Published: 2026-09-11T12:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Django](), [Python](), [LLMs](), [releases]() Tags: [2026](), [developers](), [django](), [llms](), [news](), [podcast](), [python](), [reproducible-builds](), [survey]() ### AI overview Episode 311 discusses findings from the 2026 Django Developers Survey, including how Django users are adopting LLMs in their development workflows. It also covers reproducible Python builds, recent Python and Django ecosystem releases, community news, and projects such as matchify and pydantic-pint. ### Source excerpt What are the latest trends uncovered in the 2026 Django Developers Survey? How are Django users employing LLMs in their development process? Christopher Trudeau is back on the show this week with another batch of PyCoder's Weekly articles and projects. ## Reproducible Builds summit 2026 to take place in Gothenburg DevFeed: [Reproducible Builds summit 2026 to take place in Gothenburg]() Original publisher: [Read original article]() Published: 2026-08-12T00:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [builds]() Tags: [2026](), [collaboration](), [event](), [events](), [inclusive](), [innovation](), [org](), [reproducible-builds](), [summit](), [tools](), [users]() ### AI overview The Reproducible Builds summit will take place in Gothenburg, Sweden, from September 22 to 24, 2026. The event will bring together participants to discuss project status, collaboration, broader adoption, and technical solutions. ### Source excerpt This event is happening soon -- see below for registration instructions! We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from September 22nd--24th 2026 in the city of Gothenburg, Sweden. This year, we are thrilled to host the tenth edition of this exciting event, following the success of previous summits in various iconic locations around the world, including Vienna (2025), Hamburg (2023--2024), Venice (2022), Marrakesh (2019), Paris (2018), Berlin (2017), Berlin (2016) and Athens (2015). If you're excited about joining us this year, please make sure to read the event page which has more details about the event and location. As in previous years, we will be sending invitations to all those who attended our previous summit events or expressed interest to do so. However, even if you do not receive a personal invitation, please do email the organizers and we will find a way to accommodate you. About the event The Reproducible Builds Summit is 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. Schedule Although the exact content of the meeting will be shaped by the participants, the main goals will include: Update & exchange about the status of reproducible builds in various projects. Improve collaboration both between and inside projects. Expand the scope and reach of reproducible builds to more projects. Work together and hack on solutions. Establish space for more strategic and long-term thinking than is possible in virtual channels. Brainstorm designs on tools enabling users to get the most benefits from reproducible builds. Discuss how reproducible builds w ## What Is a Container Registry and How to Use One DevFeed: [What Is a Container Registry and How to Use One]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-10T17:48:35Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [container images](), [content addressed store](), [Docker Hub](), [Dockerfile](), [supply-chain-security]() Tags: [base-images](), [cache](), [ci-cd](), [cloud](), [container-images](), [container-registry](), [containers](), [content-addressed-store](), [cryptographic](), [devops](), [docker](), [docker-hub](), [docker-login](), [docker-pull-rate-limits](), [docker-registry](), [harbor](), [image-manifest](), [image-retention-policy](), [image-scanning](), [image-tags-vs-digests](), [kubernetes](), [private-registry](), [pull-through-cache](), [reproducible-builds](), [security](), [supply-chain-security]() ### AI overview This guide explains how container registries store and distribute container images, emphasizing the distinction between mutable tags and immutable content digests. It also covers pushing, pulling, authentication, Docker Hub rate limits, caching, scanning, and retention. ### Source excerpt A tag is a bookmark somebody else can move. A digest is the image itself. Once that distinction lands, reproducible builds, supply chain security, and every it worked yesterday mystery make sense. ## Fighting Hyrum's Law in LLVM DevFeed: [Fighting Hyrum's Law in LLVM]() Original publisher: [Read original article]() Published: 2026-05-10T07:00:00Z Content type: article Language: en Sources: [MaskRay]() Topics: [LLVM](), [Compiler](), [reproducible builds](), [hash]() Tags: [clang](), [compiler](), [hash](), [lld](), [llvm](), [reproducible-builds](), [test]() ### AI overview This article examines how LLVM can develop dependencies on unspecified or incidental behavior under Hyrum's Law, causing output variation that harms reproducible builds, bisection, and bug reports. It describes hash-seed perturbation, reverse container iteration, and iterator invalidation checks as mechanisms for exposing such dependencies. ### Source excerpt With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody. -- Hyrum's Law In a compiler, the most common form of Hyrum's Law is dependence on unspecified behavior -- hash bucket order, the order of equal elements after std::sort, padding offsets. The same framing covers a few cases that are technically undefined behavior (use of an invalidated iterator) or plain incidental properties (ABI struct layout, ELF section offsets). When the compiler itself harbors such a dependency, the symptom is usually output that varies build-to-build: an unstable sort that lands differently after the standard library changes, a hash map whose iteration order shifts when the hash function does. Occasionally the variation is run-to-run within a single build -- DenseMap keys with an ASLR-derived seed reorder buckets each invocation. Either way, reproducible builds, bisection, and bug reports all assume same input -> same output, and a stealth Hyrum dependency breaks that. This post surveys some mechanisms that perturb the contract's blind spots so dependencies cannot quietly form. ## ESP-IDF Installation Manager v0.8: Streamlined Setup for ESP-IDF Development DevFeed: [ESP-IDF Installation Manager v0.8: Streamlined Setup for ESP-IDF Development]() Original publisher: [Read original article]() Author: John Lee Published: 2026-03-02T00:00:00Z Content type: release Language: en Sources: [Blog on Developer Portal]() Topics: [ESP-IDF](), [cross-platform](), [Espressif](), [Package manager](), [CI/CD]() Tags: [beginner](), [blog](), [cross-platform](), [dependencies](), [eim](), [esp-idf](), [esp-idf-tool](), [espressif](), [gui](), [installation](), [linux](), [macos](), [offline](), [pipelines](), [release](), [reproducible-builds](), [toolchains](), [windows]() ### AI overview ESP-IDF Installation Manager v0.8 adds native package-manager installation methods, offline ESP-IDF installation, improved environment activation, CI/CD integration, and version management across Windows, macOS, and Linux. ### Source excerpt The ESP-IDF Installation Manager (EIM) v0.8 introduces simplified installation across Windows, macOS, and Linux through native package managers. This article covers the new release features, installation methods, offline capabilities, and headless usage for CI/CD pipelines. ## Reviving a Static Blog with Nix and Reproducible Builds DevFeed: [Reviving a Static Blog with Nix and Reproducible Builds]() Original publisher: [Read original article]() Published: 2026-02-22T00:00:00Z Content type: tutorial Language: en Sources: [Marco Pivetta]() Topics: [Nix](), [reproducible builds](), [Composer](), [PHP](), [GitHub](), [WordPress](), [pull-requests]() Tags: [blog](), [dependencies](), [github](), [php](), [pull-request](), [reproducible-builds](), [wordpress]() ### AI overview The author returns to blogging and explains how they stabilized a Sculpin-based static website by using Nix Flakes to pin dependencies and support reproducible builds. The article also covers Composer dependency hashing and deployment to GitHub Pages. ### Source excerpt I'm back! The last time I blogged was in 2017: a lot has changed since then, and after a decade of ignoring blogging, I will attempt to put some regularity into it again. The times call for it: having a personal space that is really "our own" is extremely important, and it is as important as having something to read that is written by other humans, and not slop. I mainly stopped blogging for two reasons: Wordpress and similar tools are terrible, for rarely changing content. I'd rather not blog, than host a dynamic website just for serving static webpages My static site generation pipeline heavily relied on my workstation's software dependencies, which shifted continuously, breaking the website build at all times. Stabilizing the build Note: This section describes the Nixification of the blog, done in this pull request. You can skip this, if you prefer reading the PR instead. The first thing to do is to get everything under control again. Since a few years back, I started heavily relying on Nix, a lazy functional language that is perfect to achieve reproducible builds and environments. At the time of this writing, this website is built via Sculpin, a static website generator whose dependency upgrades I've neglected for far too long. In order to "freeze" the build in time, I used a Nix Flake to pin all the dependencies down, preventing any further shifts in dependency versions: { inputs = { nixpkgs.url = "github:nixos/nixpkgs?ref=nixos-unstable"; flake-utils.url = "github:numtide/flake-utils"; }; outputs = { self, nixpkgs, flake-utils, composer2nix, ... }@inputs: flake-utils.lib.eachDefaultSystem ( system: { packages = { # things that will stay extremely stable will go here }; } ); } The above will "pin" dependencies such as composer or php, preventing them from drifting apart, unless a commit moves them. This is also thanks to the built-in flake.lock mechanism of Nix Flakes. Because Composer does not compute content hashes of PHP dependencies, NixOS cannot directly u ## Strengthening your Software Supply Chain DevFeed: [Strengthening your Software Supply Chain]() Original publisher: [Read original article]() Author: Andres Almiray Published: 2025-12-12T03:03:02Z Content type: article Language: en Sources: [Java Advent Calendar]() Topics: [supply-chain-security](), [reproducible builds](), [Java](), [Software](), [Maven]() Tags: [2025](), [build-tools](), [dependencies](), [devops](), [integrity](), [java](), [reproducible-builds](), [security](), [software-supply-chain](), [supply-chain]() ### AI overview This article explains how to strengthen the Java software supply chain beyond relying on build tools alone. It discusses SLSA security controls, attacks such as Log4Shell and the XZ backdoor, reproducible artifacts, and support from JReleaser for applying these practices. ### Source excerpt According to Wikipedia, a software supply chain is the components, libraries, tools, and processes used to develop, build, and publish a software artifact. The Java space provides thousands upon thousands of libraries that may be consumed as dependencies for building projects. Many of these libraries rely on Apache Maven as their build tool of choice, [...] The post Strengthening your Software Supply Chain appeared first on JVM Advent. ## JavaScript's dependency ecosystem needs stronger supply-chain security and package management DevFeed: [JavaScript's dependency ecosystem needs stronger supply-chain security and package management]() Original publisher: [Read original article]() Author: September Published: 2025-09-17T00:00:00Z Content type: opinion Language: en Sources: [Drew DeVault]() Topics: [JavaScript](), [Package Management](), [npm](), [Linux]() Tags: [dependency-management](), [javascript](), [linux](), [npm](), [reproducible-builds](), [supply-chain]() ### AI overview This opinion article argues that JavaScript's dependency ecosystem should respond to supply-chain attacks by reducing sprawling dependency trees and adopting stronger trust, package-signing, distribution, and reproducible-build practices. It also proposes a standard library and more consolidated packages. ### Source excerpt In the wake of the largest supply-chain attack in history, the JavaScript community could have a moment of reckoning and decide: never again. As the panic and shame subsides, after compromised developers finish re-provisioning their workstations and rotating their keys, the ecosystem might re-orient itself towards solving the fundamental flaws that allowed this to happen. After all, people have been sounding the alarm for years that this approach to dependency management is reckless and dangerous and broken by design. Maybe this is the moment when the JavaScript ecosystem begins to understand the importance and urgency of this problem, and begins its course correction. It could leave behind its sprawling dependency trees full of micro-libraries, establish software distribution based on relationships of trust, and incorporate the decades of research and innovation established by more serious dependency management systems. Perhaps Google and Mozilla, leaders in JavaScript standards and implementations, will start developing a real standard library for JavaScript, which makes micro-dependencies like left-pad a thing of the past. This could be combined with a consolidation of efforts, merging micro-libraries into larger packages with a more coherent and holistic scope and purpose, which prune their own dependency trees in turn. This could be the moment where npm comes to terms with its broken design, and with a well-funded effort (recall that, ultimately, npm is GitHub is Microsoft, market cap $3 trillion USD), will develop and roll out the next generation of package management for JavaScript. It could incorporate the practices developed and proven in Linux distributions, which rarely suffer from these sorts of attacks, by de-coupling development from packaging and distribution, establishing package maintainers who assemble and distribute curated collections of software libraries. By introducing universal signatures for packages of executable code, smaller channels and ## Panic! At The Distro: A Study of Malware Prevention in Linux Distributions DevFeed: [Panic! At The Distro: A Study of Malware Prevention in Linux Distributions]() Original publisher: [Read original article]() Published: 2024-12-17T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [Linux](), [Malware](), [Maintainers](), [open-source-security](), [Benchmark](), [dataset]() Tags: [alpine](), [benchmark](), [dataset](), [debian](), [distribution](), [false-positives](), [linux](), [maintainers](), [malware](), [malware-prevention](), [open-source-software](), [reproducible-builds](), [research](), [scanners](), [software-supply-chain](), [wolfi]() ### AI overview Chainguard studies malware prevention in Linux distributions through maintainer interviews and a Linux package malware benchmark dataset. The study reports that most interviewed distributions do not proactively scan repositories, while existing open-source malware scanners often produce false positives. ### Source excerpt Chainguard wanted to know more about malware prevention in Linux distributions. So we did a study to see what maintainers are doing about it. See the results. ## Reproducible Builds mourns the passing of Lunar DevFeed: [Reproducible Builds mourns the passing of Lunar]() Original publisher: [Read original article]() Published: 2024-11-14T15:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [free software](), [Debian](), [open-source-security]() Tags: [debian](), [free-software](), [org](), [reports](), [reproducible-builds]() ### AI overview The Reproducible Builds community announces the death of founding member Jérémy Bobbio, known as Lunar, and reflects on his contributions to Reproducible Builds, Debian, Tor, and free software security. ### Source excerpt The Reproducible Builds community sadly announces it has lost its founding member. Jérémy Bobbio aka 'Lunar' passed away on Friday November 8th in palliative care in Rennes, France. Lunar was instrumental in starting the Reproducible Builds project in 2013 as a loose initiative within the Debian project. Many of our earliest status reports were written by him and many of our key tools in use today are based on his design. Lunar was a resolute opponent of surveillance and censorship, and he possessed an unwavering energy that fueled his work on Reproducible Builds and Tor. Without Lunar's far-sightedness, drive and commitment to enabling teams around him, Reproducible Builds and free software security would not be in the position it is in today. His contributions will not be forgotten, and his high standards and drive will continue to serve as an inspiration to us as well as for the other high-impact projects he was involved in. Lunar's creativity, insight and kindness were often noted. He will be greatly missed. Other tributes: Anargeek.net [FR] LWN Debian Stefano Zacchiroli Linuxfr.org [FR] Software Heritage A history of the Reproducible Builds project ## What's new in TensorFlow 2.18 DevFeed: [What's new in TensorFlow 2.18]() Original publisher: [Read original article]() Author: TensorFlow Blog (noreply@blogger.com) Published: 2024-10-28T19:00:00Z Content type: release Language: en Sources: [The TensorFlow Blog]() Topics: [Tensorflow](), [releases](), [LiteRT](), [NumPy](), [CUDA](), [cudnn](), [NCCL](), [Google]() Tags: [announcement](), [cuda](), [cudnn](), [gpu](), [litert](), [migration](), [nccl](), [nvidia](), [nvidia-rtx](), [python](), [release](), [releases](), [reproducible-builds](), [tensorflow](), [tensorflow-core]() ### AI overview TensorFlow 2.18 introduces NumPy 2.0 compatibility updates, transitions TFLite development to the LiteRT repository, and adds hermetic CUDA, cuDNN, and NCCL dependencies for more reproducible source builds. Binary packages add dedicated kernels for compute capability 8.9 GPUs, including NVIDIA RTX 40 series, L4, and L40, while dropping precompiled support for Maxwell GPUs. ### Source excerpt Posted by the TensorFlow team TensorFlow 2.18 has been released! Highlights of this release (and 2.17) include NumPy 2.0, LiteRT repository, CUDA Update, Hermetic CUDA and more. For the full release notes, please click here. Note: Release updates on the new multi-backend Keras will be published on keras.io, starting with Keras 3.0. For more information, please see https://keras.io/keras_3/. TensorFlow Core NumPy 2.0 The upcoming TensorFlow 2.18 release will include support for NumPy 2.0. While the majority of TensorFlow APIs will function seamlessly with NumPy 2.0, this may break some edge cases of usage, e.g., out-of-boundary conversion errors and numpy scalar representation errors. You can consult the following common solutions. Note that NumPy's type promotion rules have been changed (See NEP 50 for details). This may change the precision at which computations happen, leading either to type errors or to numerical changes to results. Please see the NumPy 2 migration guide. We've updated some TensorFlow tensor APIs to maintain compatibility with NumPy 2.0 while preserving the out-of-boundary conversion behavior in NumPy 1.x. LiteRT Repository We're making some changes to how LiteRT (formerly known as TFLite) is developed. Over the coming months, we'll be gradually transitioning TFLite's codebase to LiteRT. Once the migration is complete, we'll start accepting contributions directly through the LiteRT repository. There will no longer be any binary TFLite releases and developers should switch to LiteRT for the latest updates. Hermetic CUDA If you build TensorFlow from source, Bazel will now download specific versions of CUDA, CUDNN and NCCL distributions, and then use those tools as dependencies in various Bazel targets. This enables more reproducible builds for Google ML projects and supported CUDA versions because the build no longer relies on the locally installed versions. More details are provided here. CUDA Update TensorFlow binary distributions now ship with d ## Reproducible Builds at FOSDEM 2024 DevFeed: [Reproducible Builds at FOSDEM 2024]() Original publisher: [Read original article]() Published: 2024-02-08T00:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [FOSDEM](), [Arch Linux](), [Debian](), [Fedora](), [coreboot](), [software bill of materials]() Tags: [coreboot](), [debian](), [fedora](), [fosdem](), [org](), [reproducible-builds](), [software-bill-of-materials]() ### AI overview The article reports on Reproducible Builds activities at FOSDEM 2024. It highlights Holger Levsen's talk covering the project's history, current state, and future goals, along with other talks on reproducibility, confidential computing, RISC-V bootstrapping, reproducible development environments, HPC experiments, configuration options, and software bills of materials. ### Source excerpt Core Reproducible Builds developer Holger Levsen presented at the main track at FOSDEM on Saturday 3rd February this year in Brussels, Belgium. Titled Reproducible Builds: The First Ten Years... In this talk Holger 'h01ger' Levsen will give an overview about Reproducible Builds: How it started with a small BoF at DebConf13 (and before), then grew from being a Debian effort to something many projects work on together, until in 2021 it was mentioned in an Executive Order of the President of the United States. And of course, the talk will not end there, but rather outline where we are today and where we still need to be going, until Debian stable (and other distros!) will be 100% reproducible, verified by many. h01ger has been involved in reproducible builds since 2014 and so far has set up automated reproducibility testing for Debian, Fedora, Arch Linux, FreeBSD, NetBSD and coreboot. More information can be found on FOSDEM's own page for the talk, including a video recording and slides. Separate from Holger's talk, however, there were a number of other talks about reproducible builds at FOSDEM this year: Reproducible builds for confidential computing: Why remote attestation is worthless without it by Malte Poll and Paul Meyer. RISC-V Bootstrapping in Guix and Live-Bootstrap by Ekaitz. rix: an R package for reproducible dev environments with Nix by Bruno Rodrigues. Making reproducible and publishable large-scale HPC experiments by Philippe Swartvagher. Documenting and Fixing Non-Reproducible Builds due to Configuration Options by RANDRIANAINA Georges Aaron. ... and there was even an entire track on Software Bill of Materials. ## Strengthening your software supply chain security DevFeed: [Strengthening your software supply chain security]() Original publisher: [Read original article]() Published: 2024-01-08T00:00:00Z Content type: tutorial Language: en Sources: [Chainguard: Unchained]() Topics: [supply-chain-security](), [Security](), [Software](), [Vulnerabilities](), [chainguard images](), [container images](), [sigstore](), [snyk]() Tags: [chainguard](), [container-images](), [containers](), [cve](), [dependency](), [grype](), [image](), [reproducible-builds](), [sbom](), [security](), [sigstore](), [slsa](), [snyk](), [software](), [solarwinds](), [supply-chain](), [supply-chain-security](), [vulnerabilities](), [vulnerability-scanning](), [wolfi]() ### AI overview This article explains software supply chain risks from open-source and third-party components, using the SolarWinds attack as an example. It recommends verifying artifacts, signing container images, minimizing dependencies, updating software, scanning for vulnerabilities, using smaller base images, adopting reproducible builds, and increasing SLSA maturity. ### Source excerpt Secure your codebase with advanced supply chain security tactics: artifact authentication, minimal images and more from Chainguard. ## Farewell from the Reproducible Builds Summit 2023! DevFeed: [Farewell from the Reproducible Builds Summit 2023!]() Original publisher: [Read original article]() Published: 2023-11-02T00:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [reproducibility](), [builds](), [Embedded Systems]() Tags: [adb](), [apache](), [buildroot](), [builds](), [coreboot](), [debian](), [dockerignore-usage](), [fedora](), [germany](), [github](), [linux](), [maven](), [openwrt](), [org](), [reproducibility](), [reproducible-builds](), [security](), [summit](), [systemd](), [ubuntu]() ### AI overview A recap of the seventh Reproducible Builds summit in Hamburg, Germany, covering project updates, reproducibility practices, verification services, filesystem images and containers, package reproducibility, SBOMs, and related discussions. ### Source excerpt Farewell from the Reproducible Builds summit, which just took place in Hamburg, Germany: This year, we were thrilled to host the seventh edition of this exciting event. Topics covered this year included: Project updates from openSUSE, Fedora, Debian, ElectroBSD, Reproducible Central and NixOS Mapping the "big picture" Towards a snapshot service Understanding user-facing needs and personas Language-specific package managers Defining our definitions Creating a "Ten Commandments" of reproducibility Embedded systems Next steps in GNU Guix' reproducibility Signature storage and sharing Public verification services Verification use cases Web site audiences Enabling new projects to be "born reproducible" Collecting reproducibility success stories Reproducibility's relationship to SBOMs SBOMs for RPM-based distributions Filtering diffoscope output Reproducibility of filesystem images, filesystems and containers Using verification data A deep-dive on Fedora and Arch Linux package reproducibility Debian rebuild archive service discussion ... as well as countless informal discussions and hacking sessions into the night. Projects represented at the venue included: Debian, openSUSE, QubesOS, GNU Guix, Arch Linux, phosh, Mobian, PureOS, JustBuild, LibreOffice, Warpforge, OpenWrt, F-Droid, NixOS, ElectroBSD, Apache Security, Buildroot, Systemd, Apache Maven, Fedora, Privoxy, CHAINS (KTH Royal Institute of Technology), coreboot, GitHub, Tor Project, Ubuntu, rebuilderd, repro-env, spytrap-adb, arch-repro-status, etc. A huge thanks to our sponsors and partners for making the event possible: Event facilitation Platinum sponsor If you weren't able to make it this year, don't worry; just look out for an announcement in 2024 for the next event. ## Blog: How we Sign and Verify Falco Plugins and Rules DevFeed: [Blog: How we Sign and Verify Falco Plugins and Rules]() Original publisher: [Read original article]() Published: 2023-10-18T00:00:00Z Content type: article Language: en Sources: [Falco - Falco](), [Falco - The Falco blog]() Topics: [Falco](), [supply-chain-security](), [open-source-security](), [Security](), [Open Source](), [reproducible builds](), [GitHub]() Tags: [best-practices](), [branch-protection-rules](), [code-review](), [falco](), [reproducible-builds](), [rules](), [security](), [software-supply-chain]() ### AI overview This article explains how Falco v0.36.0, falcoctl 0.6.1, and the 0.7.0 Helm chart improve the security of Falco plugins and rule sets. It describes their OCI-based distribution and discusses safeguards against software supply chain attacks, including signing, verification, branch protection, code review, reproducible builds, dependency pinning, build isolation, and MFA. ### Source excerpt Falco v0.36.0 and the Software Supply Chain (SSC) security The latest stable Falco release, v0.36.0, alongside falcoctl 0.6.1 and the 0.7.0 Helm chart introduced new features and improvements to the security of Falco's software supply chain artifacts. Falco's two main downloadable artifacts are plugins and rule sets. They're shipped in the OCI specification format and distributed through the official Falcosecurity OCI repositories. Software supply chain attacks aim at injecting malicious code into software components, to compromise downstream users. These types of attacks are among the primary threats in today's threat landscape. In particular, attackers abuse trust relationships existing between the different open-source stakeholders. The increase in attacks on open-source software throughout the last few years demonstrates that attackers consider them a viable means for spreading malware. SSC safeguards Securing the software supply chain may seem daunting at first glance, but there are a lot of safeguards that can be put in action. And there are ways to categorize them, and ways to prioritize them. Safeguards against supply chain attacks can be classified by control type: directive, preventive, detective, corrective, and recovery. But there ain't no such thing as a free lunch. Besides safeguard classifications, the utility-to-cost ratio can also be an important factor in deciding where to start in improving the supply chain security of software, and can be pretty easy to measure it. There are cheap preventive safeguards that can be implemented in open source projects especially, where stakeholders platea can be pretty wide considering the contributions. For example, branch protection rules are usually simple per-code repository configurations in providers (e.g. GitHub) and alongside pull request-based flows enforcing code review quorum, are also standard best practices nowadays. The same applies to reproducible builds, dependency pinning, build steps isolation, MF ## Supporter spotlight: Simon Butler on business adoption of Reproducible Builds DevFeed: [Supporter spotlight: Simon Butler on business adoption of Reproducible Builds]() Original publisher: [Read original article]() Published: 2023-08-01T11:00:00Z Content type: article Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [Open Source](), [Software Engineering](), [data](), [Internet of things]() Tags: [adoption](), [builds](), [open-source](), [org](), [reproducible-builds](), [research](), [software-engineering](), [spotlight]() ### AI overview This supporter spotlight interviews Simon Butler, a software engineering researcher at the University of Skövde, about a collaborative project with six Swedish businesses that use open source software. The project's paper examines the businesses' knowledge of, experience with, and perceived value of Reproducible Builds. ### Source excerpt The Reproducible Builds project relies on several projects, supporters and sponsors for financial support, but they are also valued as ambassadors who spread the word about our project and the work that we do. This is the seventh instalment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by featuring the Civil Infrastructure Platform project, and followed this up with a post about the Ford Foundation as well as recent ones about ARDC, the Google Open Source Security Team (GOSST), Bootstrappable Builds, the F-Droid project and David A. Wheeler. Today, however, we will be talking with Simon Butler, an associate senior lecturer in the School of Informatics at the University of Skövde, where he undertakes research in software engineering that focuses on IoT and open source software, and contributes to the teaching of computer science to undergraduates. Chris: For those who have not heard of it before, can you tell us more about the School of Informatics at Skövde University? Simon: Certainly, but I may be a little long-winded. Skövde is a city in the area between the two large lakes in southern Sweden. The city is a busy place. Skövde is home to the regional hospital, some of Volvo's manufacturing facilities, two regiments of the Swedish defence force, a lot of businesses in the Swedish computer games industry, other tech companies and more. The University of Skövde is relatively small. Sweden's large land area and low population density mean that regional centres such as Skövde are important and local universities support businesses by training new staff and supporting innovation. The School of Informatics has two divisions. One focuses on teaching and researching computer games. The other division encompasses a wider range of teaching and research, including computer science, web development, computer security, network administration, data science and so on. Chris: You recently had a ope ## Reproducible Builds Summit 2023 in Hamburg DevFeed: [Reproducible Builds Summit 2023 in Hamburg]() Original publisher: [Read original article]() Published: 2023-07-05T00:00:00Z Content type: release Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [builds]() Tags: [berlin](), [collaboration](), [developers](), [event](), [germany](), [innovation](), [org](), [reproducible-builds](), [summit]() ### AI overview The article announces the Reproducible Builds Summit 2023, scheduled for October 31 to November 2 in Hamburg, Germany. It describes the event's goals, including sharing project updates, improving collaboration, expanding the effort, and developing tools and strategies for reproducible builds. ### Source excerpt We are glad to announce the upcoming Reproducible Builds Summit, set to take place from October 31st to November 2nd, 2023, in the vibrant city of Hamburg, Germany. This year, we are thrilled to host the seventh edition of this exciting event following the success of previous summits in various iconic locations around the world, including Venice (2022), Marrakesh (2019), Paris (2018), Berlin (2017), Berlin (2016) Athens (2015). If you're excited about joining us this year, please make sure to read the event page which has more details about the event and location. As in previous years, we will be sending invitations to all those who attended our previous summit events or expressed interest to do so. However also without receiving such a personal invitation please do email the organizers and we will find a way to accommodate you. About the event The Reproducible Builds Summit is 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. With your help, we will bring this space (and several other inside areas) into life: The outside area at dock-europe (source: dock-europe.net) Schedule Although the exact content of the meeting will be shaped by the participants, the main goals will include: Update & exchange about the status of reproducible builds in various projects. Improve collaboration both between and inside projects. Expand the scope and reach of reproducible builds to more projects. Work together and hack on solutions. Establish space for more strategic and long-term thinking than is possible in virtual channels. Brainstorm designs on tools enabling users to get the most benefits from reproducible builds. Di ## Reproducing Chainguard's reproducible image builds DevFeed: [Reproducing Chainguard's reproducible image builds]() Original publisher: [Read original article]() Published: 2023-07-05T00:00:00Z Content type: tutorial Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [supply-chain-security](), [configuration](), [Tooling]() Tags: [apko](), [attestation](), [build](), [chainguard](), [chainguard-images](), [configuration](), [cosign](), [hardened-images](), [locks](), [reproducibility](), [reproducible-builds](), [secure-image](), [security](), [software-supply-chain](), [supply-chain-security](), [wolfi]() ### AI overview A tutorial explaining how to reproduce a Chainguard Images build using cosign and apko. It describes locking image configurations and notes caveats involving tooling changes and withdrawn packages. ### Source excerpt Learn how to reproduce a Chainguard Images build using cosign and apko. ## Supporter spotlight: David A. Wheeler on supply chain security DevFeed: [Supporter spotlight: David A. Wheeler on supply chain security]() Original publisher: [Read original article]() Published: 2022-12-15T12:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [supply-chain-security](), [Security](), [reproducible builds](), [linux foundation](), [open-source-security](), [Open Source](), [compilers]() Tags: [compilers](), [linux](), [linux-foundation](), [open-source-security](), [org](), [reproducible-builds](), [security](), [software](), [supply-chain-security]() ### AI overview An interview with David A. Wheeler, the Linux Foundation's Director of Open Source Supply Chain Security, about improving security across open source software development, builds, distribution, and use. It also discusses reproducible builds and Diverse Double-Compiling as a way to detect trusting trust attacks. ### Source excerpt The Reproducible Builds project relies on several projects, supporters and sponsors for financial support, but they are also valued as ambassadors who spread the word about our project and the work that we do. This is the sixth instalment in a series featuring the projects, companies and individuals who support the Reproducible Builds project. We started this series by 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. Today, however, we will be talking with David A. Wheeler, the Director of Open Source Supply Chain Security at the Linux Foundation. Holger Levsen: Welcome, David, thanks for taking the time to talk with us today. First, could you briefly tell me about yourself? David: Sure! I'm David A. Wheeler and I work for the Linux Foundation as the Director of Open Source Supply Chain Security. That just means that my job is to help open source software projects improve their security, including its development, build, distribution, and incorporation in larger works, all the way out to its eventual use by end-users. In my copious free time I also teach at George Mason University (GMU); in particular, I teach a graduate course on how to design and implement secure software. My background is technical. I have a Bachelor's in Electronics Engineering, a Master's in Computer Science and a PhD in Information Technology. My PhD dissertation is connected to reproducible builds. My PhD dissertation was on countering the 'Trusting Trust' attack, an attack that subverts fundamental build system tools such as compilers. The attack was discovered by Karger & Schell in the 1970s, and later demonstrated & popularized by Ken Thompson. In my dissertation on 'trusting trust' I showed that a process called 'Diverse Double-Comp ## Reproducible builds with GoReleaser DevFeed: [Reproducible builds with GoReleaser]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2022-04-26T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [reproducible builds](), [builds](), [Go](), [GitHub Actions]() Tags: [builds](), [github-actions](), [go](), [reproducible-builds]() ### AI overview This tutorial explains how GoReleaser can help produce reproducible Go binary builds by controlling timestamps, build paths, repository state, dependencies, and tool versions. It notes that the Go version must also be pinned, for example in GitHub Actions. ### Source excerpt GoReleaser can help you, to some extent, to have reproducible builds. ## Reproducible codesigning on Apple Silicon DevFeed: [Reproducible codesigning on Apple Silicon]() Original publisher: [Read original article]() Author: Keith Smiley Published: 2021-10-06T03:00:00Z Content type: article Language: en Sources: [Keith Smiley]() Topics: [Arm](), [x86](), [C](), [Command-line interface](), [toolchain](), [Open Source]() Tags: [apple](), [architecture](), [arm](), [binaries](), [c](), [clang](), [code](), [command-line](), [identifier](), [open-source](), [reproducible-builds](), [signing](), [source](), [x86]() ### AI overview The article explains why codesigning universal macOS binaries can produce different results on Apple Silicon and Intel Macs, despite the binaries being identical before signing. It traces the issue through Apple's open-source code and identifies architecture-dependent UUID handling as the cause of non-reproducible codesigning. ### Source excerpt For people who expect reproducible builds, Apple Silicon machines provide an interesting challenge. Apple Silicon requires arm64 binaries, including command line tools you build yourself, be codesigned. This change is mostly transparent to developers, because Apple updated their linker to automatically ad-hoc sign binaries1. Unfortunately, if you're interested in producing binaries that support both Intel Macs and Apple Silicon Macs, you likely want to produce a fat binary. When codesigning this binary you hit some behavior that depends on your current machine's architecture. Example You can consistently produce the same result across multiple machines when compiling a binary without signing it. Here's an example with a simple C program: $ echo "int main() { return 0; }" > main.c $ clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The shasum of main should always be the same regardless of your host machine2. On Apple Silicon machines you can see this binary has the same sha1 even if you run clang under Rosetta 23: $ arch -x86_64 clang main.c -Wl,-no_adhoc_codesign -arch arm64 -arch x86_64 -o main $ shasum main 113033b3d9a247210b49a476bbfadb2e347846fe main The issue is introduced when you codesign the binary on Apple Silicon machines versus Intel machines. You can immediately see the difference3: $ codesign --force --sign - main $ shasum main 84631e812bd480c306766ba03a728dd2565dd672 main % arch -x86_64 codesign --force --sign - main % shasum main f631b6c0daf3ffd0bb5f65d19fa045acf447a72d main We get closer to identifying the problem when you compare the details of these differences: $ codesign --force --sign - main $ codesign -dvvv main > arm.txt 2>&1 $ arch -x86_64 codesign --force --sign - main $ codesign -dvvv main > intel.txt 2>&1 $ diff -Nur intel.txt arm.txt --- intel.txt 2021-10-05 21:26:32.731918710 -0700 +++ arm.txt 2021-10-05 21:26:29.473702845 -0700 @@ -1,14 +1,14 @@ Executable=/ ## Finding Non-determinism with nixbuild.net DevFeed: [Finding Non-determinism with nixbuild.net]() Original publisher: [Read original article]() Author: support@nixbuild.net Published: 2021-01-13T00:00:00Z Content type: tutorial Language: en Sources: [nixbuild.net blog]() Topics: [Nix](), [reproducibility](), [reproducible builds](), [builds](), [content addressed store]() Tags: [blog](), [blog-post](), [build](), [reproducibility](), [reproducible-builds]() ### AI overview This blog post explains how to use Nix repeated builds to detect non-deterministic outputs by comparing build results bit for bit. It also describes how nixbuild.net records repeated-build results and can help investigate failures from past builds. ### Source excerpt During the last decade, many initiatives focussing on making builds reproducible have gained momentum. reproducible-builds.org is a great resource for anyone interested in how the work progresses in multiple software communities. r13y.com tracks the current reproducibility metrics in NixOS. Nix is particularly suited for working on reproducibility, since it by design isolates builds and comes with tools for finding non-determinism. The Nix community also works on related projects, like Trustix and the content-addressed store. This blog post summarises how nixbuild.net can be useful for finding non-deterministic builds, and announces a new feature related to reproducibility! Repeated Builds The way to find non-reproducible builds is to run the same build multiple times and check for any difference in results, when compared bit-for-bit. Since Nix guarantees that all inputs will be identical between the runs, just finding differing output results is enough to conclude that a build is non-deterministic. Of course, we can never prove that a build is deterministic this way, but if we run the build many times, we gain a certain confidence in it. To run a Nix build multiple times, simply add the -repeat option to your build command. It will run your build the number of extra times you specify. Suppose we have the following Nix expression in deterministic.nix: let inherit (import {}) runCommand; in { stable = runCommand "stable" {} '' touch $out ''; unstable = runCommand "unstable" {} '' echo $RANDOM > $out ''; } We can run repeated builds like this (note that the --builders "" option is there to force a local build, to not use nixbuild.net): $ nix-build deterministic.nix --builders "" -A stable --repeat 1 these derivations will be built: /nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv building '/nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv' (round 1/2)... building '/nix/store/0fj164aqyhsciy7x97s1baswygxn8lzf-stable.drv' (round 2/2)... /nix/store/65 ## GoReleaser: 4 years releasing software DevFeed: [GoReleaser: 4 years releasing software]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2021-01-07T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Software](), [Go](), [GitHub Actions](), [docker images](), [MkDocs](), [Refactoring](), [reproducible builds](), [parquet](), [Pull Request]() Tags: [apple-silicon](), [compression](), [docker-images](), [github-actions](), [go](), [hooks](), [linux](), [refactoring](), [reproducible-builds](), [software]() ### AI overview A four-year retrospective on GoReleaser describes improvements made over the previous year, including deprecated-setting removal, package signing and creation, build hooks, compression, shell completions, GitHub Actions migration, reproducible builds, and multi-architecture Docker image support. It also notes an Apple Silicon support pull request awaiting the Go 1.16 release. ### Source excerpt Last year, I made a blog post about GoReleaser turning 3 years old. [Next page]()