Reproducible Builds Verification Format
Santiago Torres Arias
santiago at nyu.edu
Tue May 12 21:12:05 UTC 2020
On Tue, May 12, 2020 at 11:00:41AM -1000, Paul Spooren wrote:
> Hi all,
> at the RB Summit 2019 in Marrakesh there were some intense discussions about
> *rebuilders* and a *verification format*. While first discussed only with
> participants of the summit, it should now be shared with a broader audience!
Hi, I was unfortunately unable to join the discussion in Marrakesh due
to visa issues, so I'm glad it's picked up here
> A quck introduction to the topic of *rebuilders*: Open source projects usually
> offer compiled packages, which is great in case I don't want to compile every
> installed application. However it raises the questions if distributed packages
> are what they claim. This is where *reproducible builds* and *rebuilders* join
> the stage. The *rebuilders* try to recreate offered binaries following the
> upstream build process as close as necessary.
> To make the results accessible, store-able and create tools around them, they
> should all follow the same schema, hello *reproducible builds verification
> format* (rbvf).
I'm still unsure why not just adopt the existing in-toto link metadata
schema as described here. You could use a variant of this transport
to query information about rebuilds and more. It's intended to be
generic enough to cover not only building a package but things that may
happen before and after the build process.
> Rebuilders should publish those files publicly and sign them. Tools then collect
> those files and process them for users and developers.
I think that the verification could also be encoded using in-toto layout
policies (as described in  as well). Of note, this is something I've
started 2 years ago and I've been trying to share widely.
> Ideally multiple institutions spin up their own rebuilders so users can trust
> those rbuilders and only install packages verified by them.
This is something I've been hoping to have happened by different orgs. I
know there are many organizations that want to do this as well.
I wonder if we could integrate these additional fields into the
environment portion of the link metadata to have the best of both
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the rb-general