Reproducible builds, part 1

Motivation

A user of Ubuntu might want to validate the source code of an Ubuntu package by downloading it with pull-lp-source¹ or apt-get source. This will tell them the bundle of source code from some upstream source that the packaged is based on as well as all the Debian- and Ubuntu-specific patches that have been applied. Coupled with upstream git repositories as well as Debian² and Ubuntu³ ones.

All that information provides most of the context to answer questions like “does this version of this package have this patch?”. To be honest, I still don’t feel like I know my way well enough around https://launchpad.net to put all that together.

Nevertheless the story doesn’t stop there. Other questions might arise, especially for the security concious, like “are the executables in the package faithful to the source from which they were built (or apparently built)?”. That is what reproducible builds are about.

Background information

• https://rebuilderd.com/
  • does not exit any more
  • https://web.archive.org/web/20220716202239/https://rebuilderd.com/
• https://reproducible-builds.org/
• https://github.com/bmwiedemann/theunreproduciblepackage
• Video presentation: “What Makes A Build Reproducible?”
  • Rose Judge & Joshua Lock, VMWare
  • https://youtu.be/K8Xfe1Hqyao
  • notes:
    • levels
      1. Unscripted build
      2. Repeatedable build (controlled steps (scripted))
         • if inputs are dynamic, could get different build/output
         • are build environments controlled?
         • hostnames, times, software versions, locale, …
      3. Rebuildable build (controlled inputs)
         • intermediate artifacts are archived
         • fetched artifacts are pinned and from a controlled repo
         • hostnames, times, local, …
      4. Binary reproducible (controlled states)
         • entire build environment is fully defined
         • no uncontrolled build inputs
    • does not get into details (compilation, e.g.)
• Video presentation: “Reproducible Builds: Unexpected Benefits and Problems”
  • Bernhard M. Wiedemann, SUSE
  • https://github.com/bmwiedemann/
  • https://youtu.be/RfN2eWn6c9o
  • notes:
    • 1000 rb patches for SUSE
    • typical problems:
      • timestamps, hostname, build IDs, readdir order, race conditions
      • compile-time CPU detention (uses available optimizations for build CPU)
    • surprise problems
      • profile-guided optimizations (PGO)
    • feedback from test environment
      • security (signatures)
    • surprise benefits
      • counter trusting-trust-attack with diverse double compiler (DDC)
      • control of build process can eliminate unnecessary rebuilds
      • examples of bugs found through build process
    • https://github.com/bmwiedemann/reproducibleopensuse/blob/master/howtodebug
      • give very detailed process of how to use this repo to detect and fix rp problems
      • does refer to Debian in context of submitting to upstream:
    • https://salsa.debian.org/reproducible-builds/reproducible-website
      • however, not sure how applicable debug part is to Debian or Ubuntu building as opposed to SUSE
    • execellent source of details

Article series

• Part 1 (this article)
• Part 2
• Part 3