oses
Dull but important … so, a bit like Debian itself, really
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. ®
