Reproducible Builds Verification Format

[Paul Spooren]

Hi Santiago,

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

I tried to wrap my head around this format but failed to see a clean way to
integrate those in-toto files. Could you please provide a example which only
covers the *verification build* step? From my understanding neither Archlinux
nor OpenWrt support in-toto within their specific build systems, which are
however the only distributions (or origins) that support rebuilders[1][2].

[1]: https://github.com/kpcyrd/rebuilderd
[2]: https://github.com/aparcar/openwrt-rebuilder

> 
> > 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.

I see that build-chain-verification (in-toto) and artifact-verification
(rebuilder) have their similarities. However, for me the in-toto format is only 
an option if it can be used independent of the build-chain capabilities. Ideally
in-toto is used for results and the build-systems can organically extend the in-
toto integration.
> 
> > 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 used the word institution but really meant *anyone capable of running a
rebuilder of any origin and having an audience willing to trust them*. So we
share the same goal, great :)!

> 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 don't see a way to have a generic storage of build-system specific environment
settings. Therefore I'd suggest to have an additional file storing such
information, ideally again in JSON. I think those files can get rather complex
and while extremely valuable to developers, just bloat to package-mangers
warning the end-user about hash inconsistencies between rebuilds.

-- 
Paul Spooren <mail at aparcar.org>