# reproducible builds A software build practice that enables verification by reproducing byte-for-byte identical binary packages from a given source. 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 ## 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 ## 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. ## 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. ## Inside Go -- How It Really Works: Series Kickoff DevFeed: [Inside Go -- How It Really Works: Series Kickoff]() Original publisher: [Read original article]() Author: Furkan Kolcu Published: 2025-09-11T10:16:52Z Content type: article Language: en Sources: [Furkan Kolcu - Software Engineer Blog]() Topics: [Go Language](), [Compiler](), [Concurrency](), [Code](), [Optimization](), [escape analysis](), [generics](), [modules](), [reproducible builds]() Tags: [compilation](), [concurrency](), [deep-dive](), [generics](), [go](), [go-compiler](), [go-concurrency](), [go-performance](), [go-runtime](), [golang](), [how-go-works](), [inside-go](), [internals](), [memory-management](), [performance](), [technology]() ### AI overview This article launches a technical series about how Go works internally. The planned installments cover compilation, memory management, garbage collection, concurrency, the runtime, performance tuning, interfaces, generics, modules, and reproducible builds, with code examples and runtime experiments. ### Source excerpt A deep-dive series into Go's internals. From compilation to memory management, concurrency, and performance tuning, each part unpacks how Go operates under the hood with clear explanations and real-life code examples. ## Reproducible Builds summit 2025 to take place in Vienna DevFeed: [Reproducible Builds summit 2025 to take place in Vienna]() Original publisher: [Read original article]() Published: 2025-08-20T00:00:00Z Content type: news Language: en Sources: [reproducible-builds.org]() Topics: [reproducible builds](), [builds]() Tags: [2025](), [announce](), [collaboration](), [event](), [org](), [summit](), [technical]() ### AI overview The Reproducible Builds summit is scheduled for October 28-30, 2025, in Vienna, Austria. The eighth summit will bring participants together to discuss project status, collaboration, tools, and the future of reproducible builds. ### Source excerpt We are extremely pleased to announce the upcoming Reproducible Builds summit, which will take place from October 28th--30th 2025 in the historic city of Vienna, Austria. This year, 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 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. With your help, we will bring this (and several other areas) into life: The main seminar room. 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 reproduc ## 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 ## 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. ## 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 ## 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. ## 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. ## Modules Part 03: Minimal Version Selection DevFeed: [Modules Part 03: Minimal Version Selection]() Original publisher: [Read original article]() Published: 2019-12-18T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [modules](), [Go Language](), [Dependency management](), [Algorithm](), [reproducible builds]() Tags: [algorithm](), [ardan-labs](), [blog](), [dependency](), [dependency-management](), [go](), [go-programming](), [golang](), [modules](), [programming](), [reproducible-builds]() ### AI overview This tutorial explains Go's Minimal Version Selection algorithm for choosing dependency versions. It contrasts MVS with approaches that select the latest version and illustrates how multiple modules can require different versions of a shared dependency. ### Source excerpt Series Index Why and What Projects, Dependencies and Gopls Minimal Version Selection Mirrors, Checksums and Athens Gopls Improvements Vendoring Introduction Every dependency management solution has to solve the problem of picking a version of a dependency. Many of the version selection algorithms that exist today attempt to identify the "latest greatest" version of any dependency. This makes sense if you believe semantic versioning will be applied correctly and the social contract will be respected. In these cases, the "latest greatest" version of a dependency should be the most stable and secure version and should have backwards compatibility with earlier versions. At least in the same major version dependency tree. ## Manage Dependencies With GODEP DevFeed: [Manage Dependencies With GODEP]() Original publisher: [Read original article]() Published: 2013-10-26T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Dependency management](), [Go Language](), [reproducible builds](), [Code](), [Git]() Tags: [ardan-labs](), [blog](), [build](), [code](), [dependencies](), [dependency](), [git](), [git-commit](), [go](), [go-programming](), [golang](), [import](), [install](), [management](), [packages](), [programming](), [reproducible-builds](), [version-control]() ### AI overview This tutorial explains how to use godep to manage third-party Go dependencies and create reproducible builds. It covers installing godep, creating a project, generating a Godeps file with dependency version information, and vendoring packages. ### Source excerpt Introduction If you are using 3rd party packages, (packages that you don't own or control), you will want a way to create a reproducible build every time you build your projects. If you use 3rd party packages directly and the package authors change things, your projects could break. Even if things don't break, code changes could create inconsistent behavior and bugs. Keith Rarick's tool godep is a great step in the right direction for managing 3rd party dependencies and creating reproducible builds. The godep tool gives you two options for managing dependencies. The first option creates a dependency file with version control information and then with some godep magic, the code is built against those versions. You can also Vendor your 3rd party packages inside your projects as well. You never need to change a single source code file and everything is accomplished in conjunction with the go tooling. Downloading Godep Download godep using go get and make sure your $GOPATH/bin directory is in your PATH. go get github.com/kr/godep export PATH=$PATH:$GOPATH/bin Create A Project Build your project using the 3rd party packages as you normally would. Since godep does not require you to change any import paths in the code, 'go get' the code you need and import those packages directly. To keep the post simple, I am going to use an existing program called News Search that uses one 3rd party dependency. export GOPATH=$HOME/example go get github.com/goinggo/newssearch View linked image: Screen Shot