Reproducible Builds Verification Format

[Marek Marczykowski-Górecki]

On Tue, May 12, 2020 at 05:12:05PM -0400, Santiago Torres Arias wrote:
> 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...

I would also like to know how this new format relates to already
existing and working in-toto approach. Is there some specific deficiency
in in-toto?

> [1] https://github.com/in-toto/apt-transport-in-toto

-- 
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/20200513/e4dfdd33/attachment.sig>