Reproducible images

agreed points:

  • docker image, vagrant box, etc. are all just “packages”

  • which container/VM does not matter for reproducibility
  • it does matter for ease of use/setup

  • perfect buildinfo is the goal
  • intermediate steps can be useful

notes:

  • bazel, build only from directly available sources, no net, into docker
  • fdroid, vagrant to build up on VirtualBox
  • mozilla/nix, build up images per task, never use a base image

  • docker, AWS image, VirtualBox

  • basel builds up debian/ubuntu docker images
  • all source code, local and upstream, are checked into local source repo
  • 5 base images, security and legal reviewed

  • nix could do base images, but don’t see the need yet.
  • could be used for caching to speed things up

  • with certain compilers (e.g. javac), wide variations can produce the same thing
  • can’t be a buildinfo dependency, too hard to deal with problems

  • tools for specifying buildinfo
  • blaze forces central build infrastructure, so forces standard build envs
  • nix is a build tool first, and incidentally a package manager

  • Debian images can be reproducible using snapshots, specify date to snapshots in /etc/apt/sources.list

  • it is possible to not require full buildinfo in advance, if there is a reproducible base image that builds against user input, and it reproduces any given user submitted build, then that can also generate the buildinfo

what are the benefits of bit-perfect reproducible

  • more effective caching
  • security audits, easy to track binaries to find original source
  • catching bugs by finding unexpected changes

-

Follow us on Twitter @ReproBuilds and please consider making a donation. Content licensed under CC BY-SA 4.0, style licensed under MIT. Templates and styles based on the Tor Styleguide. Logos and trademarks belong to their respective owners. Patches welcome via our Git repository (instructions) or via our mailing list.