Debian 14 cracks down on unreproducible packages

About halfway through the Debian 14 Forky" development process, its release team announced a new goal: deterministic package compilation. The Debian project's latest Bits from the release team newsletter has a goal which may not sound very big, but will mean significant extra effort in a direction that could prove to be a valuable extra security measure. "Aided by the efforts of the Reproducible Builds project, we've decided it's time to say that Debian must ship reproducible packages," wrote ReleaseTeam member Paul Gevers. "Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced or existing packages (in testing) that regress in reproducibility." Of the two links in that paragraph, the independent Reproducible Builds project does not, in this vulture's humble opinion, explain what it's all about very clearly. We feel that Debian's own Reproducible Builds wiki page does it better: It should be possible to reproduce, byte for byte, every build of every package in Debian. The Wikipedia article also has a good clear explanation, and introduces a helpful synonym: deterministic compilation. In other words, if you use the same version of the same compiler with the same options, then every time you compile an identical set of source files, the process ought to result in an identical set of binary files. This is starting to become an industry trend - for instance, when we reported on the release of FreeBSD 15 late last year, we noted that it too now promises reproducible builds. Reproducible builds in Debian have been a long time coming: The Register first reported on Debian's efforts in this direction way back in 2015. It's not an easy task, but it's a useful security measure. The idea is to ensure that binaries have not been tampered with - for instance, modified to insert malware. It permits an additional verification step, so that users or automated tools can check whether the binaries they (or their OS package manager) downloaded are byte-identical to the ones they can compile themselves. Without this, you just have to trust the distributor who compiled your OS - as Ubuntu self-appointed benevolent dictator for life" Mark Shuttleworth pointed out in 2012. (The Internet Archive has a copy of his long-gone blog post.) We also mentioned reproducible builds when we looked at NixOS Raccoon back in 2022, and tried to explain why it was a desirable thing. (Around the same time, Rocky Linux CEO Greg Kurtzer also told us that it was part of the plan for that project, too.) NixOS is already a little further down the reproducibility trail, and as we reported on its add-on Flox deployment tool in 2024, it also aims to deliver reproducible deployments. This won't directly make Debian safer. It's already one of the safer and more stable Linux distros there are, anyway. Instead, it's about infrastructure changes that make it easier to check the supply chain, and to make it possible to write software that can check and verify that what you're getting really is what you thought that you were getting. If it all works, you won't be able to tell any difference - but auditing tools will. Debian 13 came out last August, and so Debian 14 is expected in about a year - although it does not have to stick to a rigorous fixed schedule like the commercially-backed projects. (R)