Reproducible Builds Verification Format

[Santiago Torres-Arias]

> > I'm mainly arguing that if we introduce a new concept/file format (the rbvf
> > proposed above), we should be careful it won't prevent us from doing
> > useful things (like indeed running multiple separate builds of the same
> > package at the same time, or running a 'rebuild' without access to the
> > buildinfo from the original build) in the future.
> regarding format, I tried to understand in-toto but could not understand how 
> to map anything of the 3 concepts, sorry.
> 
> Regards,
> 

Hi,

I've been sketching some stuff to show, but I think it'd be wortwhile to
explain how in-toto comes into play here:

1) The rebuliders create in-toto links. The links basically contain:
    1. materials: the BUILDINFO file (and dependencies fetched, depending
      on how verbose you'd want it to be)
    2. products: any packages built
    3. A signature to authenticate the rebuilder who did this
    4. Any other information in an opaque field called "environment".
       This could be the existing rbvf fields.

2) The verification stack (say a package manager, or a viz tool) uses a
*layout* file, which essentially describes how many rebuilders are
there, and how many need to agree on the resulf of a bulid.

That's about it. The reason why in-toto is so lightweight is that it
also attempts to provide visibility to other actors downstream or
upstream, so it tries to be non-opinionated on how the metadata looks
like. You can see how the transport works with two dummy rebuilders in
this demo[1]. 

There are other aspects of in-toto that allow logic beyond rebuilding,
but it fits naturally in this usecase as it was one that was considered
from the get go.

Cheers!
-Santiago

[1] https://github.com/in-toto/apt-transport-in-toto/pull/25
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200516/02a69aab/attachment.sig>