<div dir="ltr"><div>On Tue, May 12, 2020 at 11:00 PM Paul Spooren <<a href="mailto:mail@aparcar.org">mail@aparcar.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The *rebuilders* try to recreate offered binaries following the<br>
upstream build process as close as necessary.<br>
<br>
To make the results accessible, store-able and create tools around them, they<br>
should all follow the same schema, hello *reproducible builds verification<br>
format* (rbvf).<br>
<br>
Rebuilders should publish those files publicly and sign them. Tools then collect<br>
those files and process them for users and developers.<br></blockquote><div><br></div><div>This seems useful, though I think it is helpful to describe the relationship between</div><div>the 'buildinfo' and such a 'rebuild result'.<br></div><div><br></div><div>It is already common practice for a reproducible build to record a 'buildinfo' with</div><div>information about how/where/etc the build was created (e.g. <br></div><div><a href="https://reproducible-builds.org/docs/recording/">https://reproducible-builds.org/docs/recording/</a>).</div><div>A nice property of such a buildinfo is that it can be created just from the</div><div>sources and dependencies, without needing access to any 'previous builds'</div><div>of the same artifacts - so the process is the same for 'initial builders' and</div><div>rebuilders.</div><div><br></div><div>I think rebuilders should definitely sign and share the buildinfo's produced</div><div>by their (re)builds of the artifacts. On top of that, I agree it'd be helpful to</div><div>collect buildinfo's, compare them, and publish a 'reproduction report' in a</div><div>uniform way such as how you describe.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The format is just a draft, please join in and share you thoughts. I'm happy to<br>
extend, explain and discuss all the details. Please find it here[0].<br></blockquote><div><br></div>You now describe the 'artifacts' field to only be present when the rebuild failed.</div><div class="gmail_quote">Perhaps it would make sense to always include it (though<div>perhaps not always populate all fields), to make it more explicit what exactly</div><div>has been compared?</div><div><br></div><div>Also, I think one build can result in multiple buildinfo's, and each buildinfo</div><div>might in turn cover multiple output files. Perhaps the 'artifacts' field could</div><div>be layered to reflect that structure?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As a proof of concept, there is already a *collector* which compares upstream<br>
provided packages of Archlinux and OpenWrt with the results of rebuilders.<br>
Please see the frontend here[1].<br>
<br>
If you already perform any rebuilds of your project, please contacy me on how to<br>
integrate the results in the collector!<br></blockquote><div><br></div><div>Cool!</div><div><br></div><div><br></div><div>Arnout<br></div></div></div>