Debian must ship reproducible packages
robalni
348 points
144 comments
May 10, 2026
Related Discussions
Found 5 related stories in 78.8ms across 8,303 title embeddings via pgvector HNSW
- Arch Linux now has a bit-for-bit reproducible Docker image speckx · 40 pts · April 21, 2026 · 55% similar
- Debian decides not to decide on AI-generated contributions jwilk · 306 pts · March 10, 2026 · 50% similar
- I Built a Reproducible Mac Setup with Nix akane8 · 11 pts · April 05, 2026 · 43% similar
- 'No way to prevent this,' says only package manager where this regularly happens alligatorplum · 286 pts · May 16, 2026 · 41% similar
- The State of Immutable Linux JustinGarrison · 24 pts · March 27, 2026 · 40% similar
Discussion Highlights (20 comments)
blueflow
zero improvement on end-user experience. does not solve supply chain issues, debian package will reproducabily contain the malware from upstream.
shevy-java
A small step for debian, giant leap for mankind.
jaypatelani
Good thing. NetBSD has fully reproductible build since 2017. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...
kkfx
Debian, like any other legacy distro, mush became declarative, because the '80s model of manual deploy and the absurd pain of D/I and Preseed must end.
Zopieux
A great milestone, congrats Debian on taking a stance and holding high standards for yourself, especially in the current era.
inglor_cz
Has anyone fought Microsoft Visual Studio successfully to produce reproducible builds of C++ programs? From what I have heard, it is one of the worst contexts to do it.
pixel_popping
Forbidden You don't have permission to access this resource. Apache Server at lists.debian.org Port 443 :/
perlgeek
https://wiki.debian.org/ReproducibleBuilds has some more infos; some is outdated, but it also has a chart showing how many packages are built in the CI, and how many of those are reproducible builds. (Orange = FTBR = "failed to build reproducibly") I'm not good at reading numbers from charts, but I'd guess it's a few percent (4-5ish?).
uecker
This is a huge achievement for Debian and the free software world. It took a while though until this was understood. In 2007 when pointing out on debian-devel that this is needed, I was still told what huge waste of time this would be. And indeed it took a huge amount of work by many people to get there, but it is well worth it.
charcircuit
So much time has been wasted on reproducible builds which could have better spent on securing more important parts of Debian. Practically minor changes like a build timestamp being different is not an issue.
micw
I wonder why this is a thing nowadays. I use yocto for embedded devices and it was almost a no-brainer to implement reproducible builds. I can also easily enable Debian package management, so everything is already available.
einpoklum
Debian must ship packages without the hard dependence on systemd.
suprjami
I am always surprised Debian are leading this and not the commercial vendors. You'd think big organisations paying for RHEL and Ubuntu would be beating down the door for verifiable binaries.
Hendrikto
Why the fuck does that site break the back button? DO NOT do that.
TacticalCoder
What people really don't understand about reproducible builds is that they're not a guarantee that there's no backdoor. They're a guarantee that if there's a backdoor, it's reproducible 100% of the time. This is a godsend for white hats fighting the good fight. And, as a side note, it's strongarming vs the bad guys: "Would be too bad if we could reproduce your shiny exploit 100% of the time wouldn't it!?" . Note that we should go further (but it's a bit orthogonal to reproducible builds): builds of the final binary/package should happen by first entirely discarding all files not necessary for the final build (like all test cases and all test assets). The build should literally happen in an environment that gets rid of those (after, of course, having test in another environment that all tests cases succeed): if I'm not mistaken get rid of test assets would have stopped Jia Tan's XZ backdoor attempt dead in its track (for example). Because IIRC there were binary data part of the backdoor hidden in some asset only used by test cases. P.S: as a bonus they also allow to detect bit-flips (I'm not saying there aren't other ways to detect bit-flips: what I'm saying is that if you have deterministic builds anyway and something doesn't reproduce correctly due to a flipped-bit, it's going to be noticed).
tofflos
amd64 forky reproduced: 97.02% good: 17586 bad: 511 fail: 30 unknown: 0 This, statistics for other architectures, and the reasons for unreproducibility can be found at https://reproduce.debian.net .
amelius
That's cool but I'm honestly a bit disappointed in how apt refused to embrace/support both the container and AI/GPU aspects of computing. Are we going to see some changes there?
kkyktkrkekk
”Optimize the code for 5 seconds”, as many compilers, including vc++ on windows did, was probably one of the dumbest thing ever invented. It meant that the binaries became more optimized when building on faster computers.
jgneff
I'm so happy to see this change. I got involved with reproducible builds in 2021 after reading in horror about the SolarWinds attack. [1] I think Magnus Ihse Bursie said it best while working on reproducible builds of OpenJDK: "If you were to ask me, the fact that compilers and build tools ever started to produce non-deterministic output has been a bug from day one." [2] [1] https://www.linux.com/news/preventing-supply-chain-attacks-l... [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997
rurban
... and most of this work is done by other distros and maintainers. Starting with binutils