Differences between revisions 38 and 39
Revision 38 as of 2015-05-03 20:17:09
Size: 14845
Editor: Lunar
Comment: add slides from talk about reproducible builds in Go
Revision 39 as of 2015-05-11 12:23:11
Size: 14984
Editor: HolgerLevsen
Comment: add dhole's 1st GSOC 2015 post
Deletions are marked like this. Additions are marked like this.
Line 105: Line 105:
 * 2015-05-10: [[https://dhole.github.io/post/reproducible_builds_debian_gsoc2015/|Reproducible builds on Debian for GSoC 2015]] by dhole

With free software, anyone can inspect the source code for malicious flaws. But Debian provide binary packages to its users. The idea of “deterministic” or “reproducible” builds is to empower anyone to verify that no flaws have been introduced during the build process by reproducing byte-for-byte identical binary packages from a given source.

Why do we want reproducible builds?

  • Allow independent verifications that a binary matches what the source intended to produce.
    • Should reproducible uploads become mandatory, then the incentive of an attacker to compromise the system of a developer with upload rights is lowered because it is not anymore possible for the developer to upload a binary that does not match the uploaded sources.
    • Additionally, the incentive for this kind of attack is further lowered because an attacker now has to compromise all machines that can check the reproducibility of the uploaded source.
    • Finally, with a sufficiently large body of independent (geographically and administratively) machines, reproducible builds can help find systems which are compromised in a way to produce binaries with altered functionality.
  • Help Multi-Arch: same packages co-installation (as they need every matching file to be byte identical).

  • Be able to generate debug symbols for packages which do not have a “debug package”.
  • Ensure packages can be built from source. The archive could be made to only accept reproducible uploads: the maintainer would stop uploading .deb files but keep them referenced in the .changes. A buildd would then build the source. Only if the hash matches the upload gets accepted.
  • Allow file-level deduplication on Debian mirror sites, or maybe snapshots.d.o, of .deb files whose contents didn't really change between versions.
  • Allow .deb deltas to be smaller.
  • Packages with build profiles must offer the exact same functionality for all profiles. Reproducible builds could be use to verify that it is the case.

  • Making sure that Architecture:all packages are build identically on different build architectures.

  • Validate cross-builds against native builds.

  • Find release critical bugs.

Reproducing builds

There are two sides to the problem: the build environment needs to be recorded during the initial build, and the same environment needs to be reproduced for later rebuilds.

Recording the environment

Information on a build will be recorded in a new control file with extension `.buildinfo`.

Reproduce the build environment

The srebuild program is a sbuild wrapper which finds a timestamp from snapshot.debian.org containing all versions of the binary packages in a .buildinfo file and then carries out the build with the right versions installed.

See srebuild.

References

Presentations

Publicity

This section lists URLs, people, and dates for when other people have publicly expressed interest, or shared information about, the project.

Related projects

  • CARE monitors the execution of the specified command to create an archive that contains all the material required to re-execute it in the same context.

Further work

Having reproducible builds allows us to trust binary packages better, because it becomes easier to have:

  • diversity of buildd location and jurisdiction - build packages in more than one location, including the developer's
  • diversity of buildd hardware, in case of hardware bugs, or malicious implants - a mix of VMs, some real hardware, different CPU manufacturers, different date of manufacture and supplier
  • diversity of people - multiple signatures on a .changes file
  • diversity of kernels, explained below

Kernel packages

Special features of kernel packages (including bootloaders and hypervisors) - GRUB2, Xen, linux, kfreebsd...

  • we put huge trust in them - kernels are the ultimate target of any rootkit, able to completely hide from userland
  • a kernel image built for amd64, if the build system is portable and reproducible enough, will be the same whether built from linux-amd64 or kfreebsd-amd64
  • or maybe from different kernel versions - for example, a jessie build chroot on a wheezy host system

Then we would be better protected from something that could affect many systems at once, such as a kernel vulnerability; or widespread infection by a rootkit, which now must be compatible with more than one type of kernel to go unnoticed.