Reproducible Builds Verification Format

[Eric Myhre]

Some of these dreams and the outlines of these concepts have been around 
quite a bit longer than this year, even.  I think some differential 
diagnosis about what makes this draft different, and why it makes the 
choices it does, would be useful.

Some things I'd like to see identified and explicitly discussed more 
frequently in this concept space:

- What's the "primary key"?  In other words, how can I meaningfully 
expect to identify this one attestation record, or this one build 
instruction document?

- What are the "secondary keys" I could plausibly expect to select on if 
I have a zillion of these, and want to find those that should or should 
not align in results?

- What parts of this info do we expect to be useful, and why?  (What 
user story caused a certain piece of info to seem relevant and 
actionable enough to include?)

- What things we *could* imagine someone proposing putting in this info 
which we might reject because we don't believe it would be useful, and why?

The motivations of "a generic way to compare results" are good.  But 
good intentions can only carry us so far.  These four things are some of 
the first considerations I have when looking at a format proposal.  
Without some thought about the "keys", I don't know how it will deliver 
on "comparability" at scale.  Without some meta-documentation of not 
just the data that goes _in_, but also the kind of data that _doesn't_, 
I worry that the spec will become a kitchen sink, sopping up more data 
with time regardless of its relevance, and correspondingly becoming less 
and less useful over time.

I don't know if these are the only four questions to ask, nor will I 
claim they are perfect, but they're some of the first things that come 
to my mind as heuristics, and I share them in the hope that they can be 
a useful whetstone for someone else's thoughts.



As an incidental aside, I think what's currently listed in that github 
link as "origin_uri" may be mistaken in its conception of "URI".  The 
examples are such things as "http://ftp.us.debian.org/" and 
"https://download.docker.com/", and I'm sure these are _locations_, not 
_identifiers_ -- URLs, not URIs.

And I would question (begging forgiveness from anyone who knows my 
refrain already) if "locations" as any sort of primary key are a sturdy 
idea to try to build upon.  They're terribly centralized. And provide 
very little insurance against mutability events which can make all other 
documents that refer to them become instantly useless.  
Content-addressing may have some potential to address this, git (at 
least in concept) has shown us the way...



Cheers to all hopeful rebuilders :)


On 5/12/20 11:00 PM, 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!
>
> 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). The format tries to be as generic as possible to cover all open
> source projects offering precompiled source code. It stores the rebuilder
> results of what is reproducible and what not.
>
> Rebuilders should publish those files publicly and sign them. Tools then collect
> those files and process them for users and developers.
>
> Ideally multiple institutions spin up their own rebuilders so users can trust
> those rbuilders and only install packages verified by them.
>
> The format is just a draft, please join in and share you thoughts. I'm happy to
> extend, explain and discuss all the details. Please find it here[0].
>
> As a proof of concept, there is already a *collector* which compares upstream
> provided packages of Archlinux and OpenWrt with the results of rebuilders.
> Please see the frontend here[1].
>
> If you already perform any rebuilds of your project, please contacy me on how to
> integrate the results in the collector!
>
> Best,
> Paul
>
>
> [0]: https://github.com/aparcar/reproducible-builds-verification-format
> [1]: https://rebuild.aparcar.org/
>