Reproducible Builds Verification Format

[Santiago Torres Arias]

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[1]. 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 [1] 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
worlds...

Thanks,
-Santiago


[1] https://github.com/in-toto/apt-transport-in-toto
-------------- 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/20200512/b323f2ef/attachment.sig>