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?
signature.asc
Description: PGP signature
