Reproducible Builds Verification Format

[Morten Linderud]

On Thu, May 14, 2020 at 01:39:57PM +0200, Arnout Engelen wrote:
> On Wed, May 13, 2020 at 10:31 PM kpcyrd <kpcyrd at rxv.cc> 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 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.

This is an implementation detail, isn't it? A buildinfo wouldn't be required if
you are in an environment where the build environment doesn't change. But in
many cases, this isn't the case. Dependencies we pulled could have new versions
which could very well interfer with the build. And if we don't have the
buildinfo file at hand, how would we know what introduced the change?

I'm unsure if you are proposing a rebuild, or argueing for multiple seperate
builds of the same package at the same point in time. The latter is beside the
goal of a rebuilder currently and would in any case be a CI/CD feature of the
given distribution.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16