Reproducible Builds in February 2022
reproducible-builds.org
reproducible-builds.org
Arch reproduces all published packages and reproducing a package as a user is as simple as running `repro pkgname.pkg.tar.gz`.
https://reproducible.archlinux.org/
https://github.com/archlinux/archlinux-repro
Do note we have multiple rebuilders. The tooling is written so you should be able to reproduce Arch packages on any distribution, but we still struggle with packages embedding "uname" into the binaries still.
I think I’ve also done that for other projects I’ve been involved with over the years.
What did the reproducibility add?
- here is binary that is currently running - here is source code previous developer left - here is scant documentation of what it is supposed to accomplish - here is what we want you to change
the first things you want to to do is confirm the source code you have can build the binaries running.
A lot of compilers, for one reason or another, like to sprinkle random crap into the binaries that makes them different every time you compile. .Net for example adds compiled time into the binary. If you try to compare the two binaries with md5/sha they will always return different.
Without reproducible builds, your next step is to run decompilers against the two binaries, and hope that that output matches.
Much easier if you have reproducible builds. This is also security feature: you will know if anyone tampered with the binary.
You know without doubt that the binary that you produced was built from the source code, because you built it.
I'm asking, why not stop there? You have a binary that you can safely consider "verified", what does it matter if it's bit-for-bit identical to any other binaries?
> I'm asking, why not stop there?
You do not know that it was built from the source code. That's precisely why you're not stopping there. For your machine, the one you're building from, may be compromised and compiling something else than the source code it's showing you (for example it may be inserting a backdoor here or there in the binary).
While if you really end up with the same build as everybody else does (and you have to really make sure of that: checking the hash from the very machine you compiled from is not be sufficient), you know for sure that the build is the same everybody else ended up with.
I encountered it when I updated a bunch of NixOS packages at once. Since the crash happened in chromium, I figured I'd downgrade that specific package by pinning an older channel. It still didn't work. But I knew that chromium had worked before, and nix doesn't really use the FHS, so the system wouldn't be polluted with random versions of packages. I also knew that the SHA for chromium had to match what was here: https://github.com/NixOS/nixpkgs/commit/a1c5e5bc40749652503c....
So if chromium wasn't the issue, the problem would have to lie elsewhere. Comparing the last two generations of my system, I found that Sway had updated, which also brought a new version of wlroots that broke older versions of chromium. I eventually found my way to this issue and rolled Sway back until the fix landed in stable.
There were probably easier/quicker ways to reach the same conclusion I did. But I think that knowing the software on my system was built correctly, and was relatively isolated (i.e. wasn't depending on random versions of libraries in the FHS) made it so I wouldn't fall down a rabbit hole that lead to a dead end.
Industry: “Virtualize it! No wait, containerize it! Use podman to run a write-once run anywhere JVM, as docker is dead. But automate that with a Dockerfile!”
Me: “glad I learned devops in multiple contexts, we have zero internal consistency.”
I giggled a bit at February 2022 being in the title since it’s March, and no notable advances have occurred in… 5 days.
(ADDENDUM: hypervisors are my preferred tech that has reached mere mortals in recent years. I’m mostly following that thread lately. Alpine linux or freebsd or macos on any box running any app? Yes, please.)