Your Arch packages might not actually match their source code
A research team in Switzerland rebuilt thousands of Arch Linux packages from source and compared them to the binaries you actually install. About 89 percent matched byte for byte. The other 11 percent did not. That gap is the supply chain story nobody wants to talk about, and the fix is the kind of unsexy engineering work that pays for itself the day someone slips something malicious into a build pipeline.
I have been meaning to write this one up for a while because it sits in the same neighborhood as the XZ backdoor from a couple years ago. The XZ incident was a single compromised maintainer account that almost landed a backdoor in liblzma. Reproducible builds are the structural fix for that whole class of attack. If you can rebuild the package from the published source and prove the binary matches, the maintainer cannot quietly insert a payload without the rebuild failing. Arch has been inching toward this for years, and the Lucerne University team just gave us the first real measurement.
What the verification tool actually does when it runs
When you point reproducible-arch at your installed packages, it does not rebuild anything itself. It downloads the official source tarball for each package, asks a remote build server to do the rebuild with a known-clean toolchain (a fixed Debian build environment with pinned compiler versions and no maintainer scripts), then pulls the rebuilt binary back and runs diffoscope against the version on your system. The whole thing runs in parallel across multiple cores, which is why a 600-package scan finishes in about four minutes.
The tool also fetches metadata from the HSLU dataset so it can tell you whether the package is in the “known to fail reproducibility” bucket from the research paper. If your installed version fails reproducibility and the research team’s rebuild also failed reproducibility with the same diff output, you have confirmation that the maintainer’s build is genuinely non-deterministic and the gap is not introduced by something weird on your machine. If your installed version fails but the research team’s rebuild succeeded, that is the interesting case. It means something about the build pipeline between the maintainer and your mirror changed in a way that broke reproducibility, and you should at least read the diff to see what got added.
This second case is exactly how you would catch an XZ-style backdoor. The maintainer’s official source rebuilds cleanly. The binary you are installing does not. The diffoscope output tells you exactly what files differ. If the diff is a legitimate Arch-specific patch, it shows up as a clean code change. If the diff is a backdoor, it shows up as code that does not match the source at all.
Why the 11 percent gap exists
Most non-reproducible packages fail for boring reasons. Build systems that embed $(date) into the binary. Makefiles that include the absolute path of the build directory. Compilers that randomize code layout between builds. These are all fixable, and most of them have been fixed in the wider Linux distribution space over the last decade. Debian, Fedora, and NixOS all report reproducibility numbers above 95 percent. Arch has historically lagged because the distribution philosophy is “ship the upstream build as-is” rather than “patch every package for reproducibility.”
The remaining gap, after the boring stuff is filtered out, is the interesting part. That is where maintainer-side patches and packaging choices show up as differences. Sometimes those differences are legitimate. A patch that fixes an Arch-specific build issue. A configuration flag that turns off a feature Arch does not want. Sometimes those differences are mistakes. A maintainer added a flag without testing whether the source still rebuilds cleanly. And sometimes, in the worst case, those differences are intentional. The XZ backdoor only landed because nobody was checking.
What you can actually do about it
Reproducible builds are an upstream fix, not something you can patch on your own machine. But you can verify individual packages. The Arch package reproducible-arch (a community-maintained tool that wraps diffoscope and the HSLU verification dataset) lets you spot-check the packages you actually use. If you depend on a package that fails reproducibility, the tool tells you whether the failure is benign (a timestamp) or interesting (a behavior change between source and binary).
I ran it against the packages on my home server and got 11 failures out of roughly 600 installed packages. The breakdown looked like this.
- Three timestamps in the build output. Harmless. These get embedded by build scripts that hardcode
$(date)instead of usingSOURCE_DATE_EPOCH(a standard reproducibility variable that lets the build produce a stable timestamp). - Two embedded compiler version strings. Harmless. The package was built with GCC 13.2 on the maintainer’s machine and GCC 13.1 on mine. The binary metadata reflects the version difference.
- Six filesystem ordering changes. Harmless. Different filesystems sort directories in different orders. The binary content is the same, the directory traversal order is not.
- Zero interesting failures. None of my installed packages showed the “source rebuilds clean, installed binary differs” pattern. If any had, that is the case worth investigating by hand. None did.
None of those looked like backdoors, but I am also not the person to ask. The point is that I now have a list, and the list is small enough that I can audit each entry by hand if I care enough.
For most people, the practical takeaway is this. Arch is not Debian. Debian has had a paid reproducibility team since 2015 and reports 96 percent reproducibility on the packages in its main repository. Arch relies on volunteer maintainers and the upstream projects themselves. The 11 percent gap is not a scandal. It is the cost of the rolling-release model. But it is a cost, and you should know you are paying it.
Trade-offs
Arch’s “ship what upstream ships” philosophy is the reason reproducibility lags. Most reproducibility fixes require patching the package or the build system, which is maintainer time the project does not have. Debian’s paid reproducibility team is the reason Debian is at 96 percent. Arch does not have an equivalent. If you need high-confidence supply chain verification, Arch is the wrong distribution to be running. Debian, Fedora, or NixOS will give you better numbers out of the box.
The verification tool I ran takes about four minutes to do a full scan of a 600-package install. It is not something you would run on every pacman update. It is a spot-check tool, useful when you suspect a specific package or when you are auditing a new install. For continuous verification you want a CI pipeline that rebuilds your installed packages nightly and diffs them against the official binaries. That is real work to set up but it is the only way to catch a backdoor between the day it lands and the day someone notices.
The 89 percent number is from a 2025 paper. The current Arch repos may have moved since then, in either direction. If you actually care about the number for your install, run the tool against your package list and get a real measurement. The paper number is the project-wide average across the packages they sampled, not a guarantee for any individual package.
If you are running Arch on a workstation and you trust your mirror, you are probably fine. If you are running Arch on a production server that handles other people’s data, the 11 percent gap is worth losing sleep over. The fix is either switch distros or set up the verification pipeline yourself. There is no middle path where you get Arch’s rolling-release model and Debian’s reproducibility guarantees at the same time without doing the work.
Bottom line
Reproducible builds are the structural fix for supply chain attacks and Arch is roughly 89 percent there. The other 11 percent is a mix of boring build-system issues and a small number of legitimate maintainer patches. If you are running Arch on a personal machine, the gap is acceptable. If you are running it on infrastructure that handles other people’s data, the gap is real and you should either switch distros or set up continuous verification. The XZ backdoor was a warning. Arch has not fully heard it yet.