Reproducible Builds Verification Format

[Arnout Engelen]

On Wed, May 13, 2020 at 10:31 PM kpcyrd <kpcyrd at rxv.cc> wrote:

> On Wed, May 13, 2020 at 09:39:40AM +0200, Arnout Engelen wrote:
> > This seems useful, though I think it is helpful to describe the
> > relationship between
> > the 'buildinfo' and such a 'rebuild result'.
> >
> > It is already common practice for a reproducible build to record a
> > 'buildinfo' with
> > information about how/where/etc the build was created (e.g.
> > https://reproducible-builds.org/docs/recording/).
> > A nice property of such a buildinfo is that it can be created just from
> the
> > sources and dependencies, without needing access to any 'previous builds'
> > of the same artifacts - so the process is the same for 'initial builders'
> > and
> > rebuilders.
> >
> > I think rebuilders should definitely sign and share the buildinfo's
> produced
> > by their (re)builds of the artifacts. On top of that, I agree it'd be
> > helpful to
> > collect buildinfo's, compare them, and publish a 'reproduction report'
> in a
> > uniform way such as how you describe.
>
> 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 don't think the buildinfo of the initial build should be a required input
for a rebuilder.

The main reason we're interested in reproducible builds is that we're not
100% confident the initial build was not tampered with. Security-wise
it would be attractive when no information needs to flow from the initial
build
to the reproducer.

Of course the party comparing the results needs information from both the
original builder and the rebuilder, but that might be a separate entity.
Perhaps that should even be the responsibility of the 'collector' rather
than of the rebuilder?

Now of course I know in practice it can be logistically convenient to use
the
buildinfo from the initial build as input for the rebuilder. I'm not saying
we
should forbid this. But I think we should design our standards / file
formats
in such a way that we do not *require* rebuilders to have access to
information
from the initial build. For example, triggering a 'rebuild' whenever a new
version is tagged in source control could in some cases be a valid approach
as well.

> 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 is copied into the binary packages, in debian it's
> published as "this is the buildinfo file for this version of this source
> package" that can then be used to setup the build environment that all
> binary packages have been built in. Please correct me if I'm wrong.
>

At least on Debian, one buildinfo can cover multiple binary artifacts: for
example see the 'Checksums-Sha256' section of the example at
https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles

In my case (building JVM libraries with sbt), a multi-project build produces
a buildinfo per subproject. It might be elegant to be able to express the
reproduction of the entire build in one 'verification', but otherwise we can
publish a 'verification' for each subproject separately I guess.


Kind regards,

Arnout
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200514/6555b1d2/attachment.htm>