Reproducible Builds Verification Format

[kpcyrd]

On Wed, May 20, 2020 at 02:17:56PM +0000, Holger Levsen wrote:
> > The buildinfo is an output of the initial build and becomes an input for
> > the rebuilder, but a rebuilder is always going to use the official
> > buildinfo when verifying the official package. I'm not sure if the
> > buildinfo of a rebuilder would be useful.
> 
> think about a malicious initial build. in this case it would be very useful
> to be able to detect that all the rebuilds get the same result, differing
> from the initial build.

I think you always need the initial build as an input to achieve this
in a reliable way, unless you have a nix-style approach to package
management. You'd need to be able to derive the build environment from
just the source input, Arch Linux doesn't have a reliable way to derive
S_D_E besides the buildinfo file and both Debian and Arch Linux are not
atomic enough to derive a list of installed packages from their S_D_E
due to mirror drift. I assume rebuilders would randomly produce
different binaries unless you ensure they all use the same environment.

> > > Also, I think one build can result in multiple buildinfo's, and each
> > > buildinfo
> > > might in turn cover multiple output files. Perhaps the 'artifacts' field
> > > could
> > > be layered to reflect that structure?
> > As far as I know there's only one buildinfo output per build. In Arch
> > Linux this file...
> 
> I'm not sure you ment 'one buildinfo file per build' but openwrt produces
> 3 .buildinfo files for each build.
> 
> Also it is imaginable that a source build which creates X artifacts also
> creates X .buildinfo files. (And sometimes I wish that Debian would do that.)

A single, canonical buildinfo file per binary package. If you build a
package in debian you may get multiple binary packages but always one
buildinfo file that describes the environment for all of them. In Arch
Linux this buildinfo file is copied into the binary packages, so every
binary package describes its own build-environment. I'm assuming OpenWRT
does the same. There are advantages and disadvantages with both
approaches.

There might be other environments that produce the same binary package,
but we need a way to determine a "blessed" environment. There are
multiple ways to do that:

- nix-style: the blessed build environment is recorded with the source
  package, (no buildinfo files are needed)
- you have a central authority that takes snapshots of the current
  environment and declares them as blessed (generating buildinfo files
  without actually building)
- the packager/builder declares their environment as blessed during the
  initial build (generating a buildinfo file during initial build)

You can also try to come up with your own environment by taking a
snapshot yourself doing your own initial build, that snapshot may be
identical and the binary outputs may also be identical, but unless the
generated buildinfo files are also identical you're basically doing
build-environment fuzzing (which I think would be awesome to have) yet I
don't think this should be done by the first generation of rebuilders.

If there are concerns with the build environment then there should be
linters for them that verify the blessed environment doesn't eg. use a
10 year old compiler. This is a problem that nix also needs to have a
solution for (and probably already has), since this is a
backdoored-build-input problem.