A goal was to minimise the conditions needed to reproduce a binary.
.buildinfo files (“buildinfo files”) would be a formula to reproduce a build. It should be small as possible.
They don’t/can’t describe every possible input; [a] build process [can be] affected by obscure things or external, variable factors.
buildinfo files: record inputs to the build that produced the output, so that you can recreate its state.
analysis of buildinfo and outputs: as more builders provide buildinfo files, we can look for intersections (reproducible binaries), and causes of any differences (non-reproducibility)
the ideal (reproducible) build would depend only the source code and build dependencies
buildinfo files should:
- contain the minimal information needed to produce a given binary
- be small, compact, and easily distributable
buildinfo files might contain:
- source package (name, version, hash?)
- binaries produced (name, arch, checksums)
- build dependencies (recursively)
- build path (until recently?)
- environment variables (since recently?)
In Debian, buildinfo is a separate file.
In Arch Linux, buildinfo is included in the package files (but signatures are detached).
Consuming and aggregating buildinfo files:
in Debian, buildinfo files are used when:
- DD uploads a package
- debian-ftp system distributes packages
- end-user installs packages
and now we also realised:
- buildinfo distributors
We want to collate and distribute buildinfo files from external parties too; not just those from Debian developers and the official builds.
Collecting and distributing those, is a quite different task than just distributing buildinfo from Debian’s official builds.
buildinfo.debian.net already collects and distributes some non-official buildinfo files.
We will need to write tools making it easy to test [reproducibility] and submit buildinfo, and tools to retrieve buildinfo files/signatures when installing.
Signed buildinfos save people from having to build every package themselves: it gives them sufficient confidence to trust pre-built binaries.
buildinfo files should to be detailed enough to explain the causes of non-reproducibility; but too much information ($HOME, hostname, installed packaged versions)
An argument arose that a normalised build environment avoids lots of reproducibility issues, like build path, environment, etc., affecting the build. Whilst that would be easier, some of us think that is really a bug in the software that ought to be fixed.
In the extreme case, when a build-dependency affects an output binary, we may need to generate a new set of buildinfo files describing that situation.
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.