Reproducible Builds,
the first eleven years and beyond!

Holger Levsen
DebConf24
2024-08-02, Busan, South Korea

Reproducible Builds,
Preserving other build artifacts

Holger Levsen
DebConf24
2024-08-02, Busan, South Korea

Who am I

1. Holger Levsen / holger@debian.org, located in Hamburg, Germany. Born at 329 ppm. He/him. 🏳️‍🌈🏳️‍⚧️🖤😷
2. Debian user since 1995, contributing since 2001, Debian member since 2007. I ❤️ Debian.
3. Working on Reproducible Builds since 2014. Aiming to make all ❤️ Free Software reproducible.
4. Ask me anything, anytime. This is a pretty complex topic.

About you

• Who has seen my talk about Reproducible Builds on Monday? (or another time)
• Who knows something about the Debian archive kit (dak)?
• Who knows something about Debian buildd infrastucture?
• Who knows about dpkg-distaddfile?

About this workshop

• I'll get to the topic at hand (how to preserve other build artifacts?) in two minutes.
• But first, some context.

Introduction

The problem

• Source code of free software available
• …most people install pre-compiled binaries
• No one really knows how they really correspond (even those building those binaries).
• As a result there are various classes of supply chain attacks.

https://reproducible-builds.org/docs/definition/

• When is a build reproducible?
• A build is reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
• The relevant attributes of the build environment, the build instructions and the source code as well as the expected reproducible artifacts are defined by the authors or distributors. The artifacts of a build are the parts of the build results that are the desired primary output.

https://reproducible-builds.org/docs/definition/

• When is a build reproducible?
• [...] The artifacts of a build are the parts of the build results that are the desired primary output.
• Build logs, unit tesst results, autopkgtest results and other build artifacts are out of scope in this definition.

100%!

• 100% reproducible is a political decision and nothing technical.
• We need to change debian-policy!
• We can work around 'must-have-offenders' using whitelists in the beginning.
• The goal is still 100%, whitelists are just a way to achieve that goal eventually.

CI results for Debian unstable, 20240727

Debian policy

• 2017: packages should build reproducibly.
• 2025? reproducible packages must not regress.
• 2025? NEW packages must build reproducibly.
• 2027? packages must build reproducibly.

future reproducibility of Debian amd64

Other build artifacts
(and other significant problems)

• So let's get to those other build artifacts finally.

Build artifacts

• .deb files (and .changes and .buildinfo)
• the one and only build logfile
• nothing else, so people who need those artifacts invented unreproducible work arounds and store these build artifacts in .deb files.
• or the workaround is to do a local build to have access to those artifacts. That's clumsy and time consuming.

https://wiki.debian.org/BuildArtifacts

• .deb files (and .changes and .buildinfo)
• the one and only build logfile
• nothing else, so people who need those artifacts invented unreproducible work arounds and store these build artifacts in .deb files.
• or the workaround is to do a local build to have access to those artifacts. Thta's clumsy and time consuming.

https://wiki.debian.org/BuildArtifacts

packages including other build artifacts

• src:binutils builds binutils-dev unreproducibly.
• src:gcc-X builds gcc-X-test-results unreproducibly.
• We cannot whitelist those packages forever, if we want 100% reproducible packages in Debian testing and stable eventually!
• Many thanks to Matthias Klose for writing https://wiki.debian.org/BuildArtifacts !

other https://wiki.debian.org/BuildArtifacts

• more than one build log.
• config.log, config.status
• preprocessed source for compiler errors
• test results (from unit tests during build, not autopkgtests)
• dejagnu test logs
• The wiki page has more usage examples, eg verbose build logs from GNOME packages. prepocessed sources in /tmp/cc*.out

Preserving build artifacts, what doesn't work:

• salsa CI: we want the artifacts from real builds.
• autopkgtest mechanism is also not dealing with results from the builds, but from tests using the build results.

Preserving other build artifacts

• dpkg-distaddfile can be used to add files to debian/files so that they are referenced in the .changes files and thus included in upload.
• files added via dpkg-distaddfile end up in the byhand queue, eg on coccia.debian.org:/srv/ftp-master.debian.org/queue/byhand
• Now we only need dak to accept those files and make them available somewhere, outside the archive, like .buildinfo files...
• (Though this doesn't work for failed builds. But then we have nothing for those now neither.)

Preserving build artifacts, how to continue...

• So we only need dak to accept those files and make them available somewhere... 💅
• Almost sounds like an easy plan.
• Almost: .buildinfo files until this day are not made available to the public by the ftpmasters...

Timeline

• Can we have this for experimental now/soon?
• and for unstable directly after the trixie releasde?
• or even earlier for unstable too?

Thank you
… and all contributors out there!

Holger Levsen <holger@reproducible-builds.org>
B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C