Lots of progress for Debian's reproducible builds

Debian does amazing amounts of system-wide initiatives. Off the top of my head, there are multiarch <a href="https://wiki.debian.org/Multiarch" rel="nofollow">https:&#x2F;&#x2F;wiki.debian.org&#x2F;Multiarch</a>, clang rebuild <a href="http://clang.debian.net/" rel="nofollow">http:&#x2F;&#x2F;clang.debian.net&#x2F;</a>, and automated code analysis <a href="https://qa.debian.org/daca/" rel="nofollow">https:&#x2F;&#x2F;qa.debian.org&#x2F;daca&#x2F;</a>.

The reproducible builds talk at 31C3 also does a nice job of explaining some of the many possible attack vectors that make reproducible builds desirable, and many of the subtleties involved in making it work: <a href="http://media.ccc.de/browse/congress/2014/31c3_-_6240_-_en_-_saal_g_-_201412271400_-_reproducible_builds_-_mike_perry_-_seth_schoen_-_hans_steiner.html" rel="nofollow">http:&#x2F;&#x2F;media.ccc.de&#x2F;browse&#x2F;congress&#x2F;2014&#x2F;31c3_-_6240_-_en_-_...</a>

This is a link shared by an LWN subscriber - usually, articles only become available for free 7 days after publication. If you read this article, please think about supporting LWN financially.

I actually did some work making debootstrap reproducible. So even if the 100 or so .deb builds it depends on are reproducible, then the chroot image resulting from debootstrap will not be reproducible byte-for-byte, due to the debootstrap shell script itself and the tools it calls.<p>Offhand, I remember that &#x2F;etc&#x2F;{passwd,group} are copied from the host machine by design. There is also a random seed file, to save entropy across reboots. And there is some nondeterminism in the dynamic linker cache AFAIK. And timestamps in logs.<p>If anyone is interested in this let me know.

It can be surprisingly difficult. Funnily enough moving from svn git in one project I know of probably did a lot of the necessary work to achieve this, by having to remove reliance on $SVN tags and pre&#x2F;post-&quot;build commits&quot; which used to be a part of the release process.<p>It&#x27;s an interesting use-case for Docker as well: you can ship the build environment (or its Dockerfile describing it) for people to run builds under the same env as the official released build.

Little bit of related trivia : Lunar (J.Bobbio) worked on hOp, a GHC based Haskell micro kernel so you can write drivers in it. See <a href="https://github.com/dls/house" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dls&#x2F;house</a>. A knowledgeable fellow.

Can anyone comment on why all builds are not currently &quot;reproducible&quot;?<p>I mean, if a package is compiled on the same system, with the same compiler, with the same build script -- should it not produce the same output?

I love this kind of projects, and I think that for Debian is one of the best things that can happens.<p>Also openSUSE have reproducible builds&#x2F;packages since ages via OBS (<a href="http://build.opensuse.org" rel="nofollow">http:&#x2F;&#x2F;build.opensuse.org</a>) and now Factory&#x2F;Tumbleweed have reproducible packages + automatic CI (using openQA: <a href="https://openqa.opensuse.org" rel="nofollow">https:&#x2F;&#x2F;openqa.opensuse.org</a>) Quite an achievement for a rolling distribution.

Baserock (<a href="http://wiki.baserock.org" rel="nofollow">http:&#x2F;&#x2F;wiki.baserock.org</a>) may have a repeatable build of OpenEmbedded for automotive systems.

Will this provide a <i>guaranteed</i> method for reproducible builds, or will it still be technically possible to create build scripts that produce different results (e.g., by pulling from &#x2F;dev&#x2F;random, or grabbing timing information from various sources, or by writing a multithreaded program whose threads all write to a single file)?