Reproducible Builds Verification Format
santiago at archlinux.org
Sat May 16 21:53:01 UTC 2020
> > 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.
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the rb-general