Reproducible Builds Verification Format

[Marek Marczykowski-Górecki]

On Thu, May 14, 2020 at 01:55:40PM +0200, Morten Linderud wrote:
> 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?

The discussion is about build verification format, not rebuilder
architecture specifically. I think what this format should represent is
a simple info to be consumed be for example package manager:

    I have built package <X>, version <Y>, with source hash <AAA> and
    got binary package(s) <BBB> with hash <CCC>.
        -- signed by (re)builder <RRR>

Other information, like what rebuilder needs to know, or what
environment was used etc could be optional, or even totally separate.
And in fact, we do have a format for that extra info already: buildinfo
file. And I think that should be kept separated.

In fact, for the sole verification purpose, IMO just source hash should
be enough (if we trust the hash we use), but for debugging purposes it
may be convenient to name the package and version anyway.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200514/cc337d06/attachment.sig>