<div dir="ltr"><div dir="ltr">On Wed, May 13, 2020 at 10:31 PM kpcyrd <kpcyrd@rxv.cc> 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">On Wed, May 13, 2020 at 09:39:40AM +0200, Arnout Engelen wrote:<br>
> This seems useful, though I think it is helpful to describe the<br>
> relationship between<br>
> the 'buildinfo' and such a 'rebuild result'.<br>
> <br>
> It is already common practice for a reproducible build to record a<br>
> 'buildinfo' with<br>
> information about how/where/etc the build was created (e.g.<br>
> <a href="https://reproducible-builds.org/docs/recording/" rel="noreferrer" target="_blank">https://reproducible-builds.org/docs/recording/</a>).<br>
> A nice property of such a buildinfo is that it can be created just from the<br>
> sources and dependencies, without needing access to any 'previous builds'<br>
> of the same artifacts - so the process is the same for 'initial builders'<br>
> and<br>
> rebuilders.<br>
> <br>
> I think rebuilders should definitely sign and share the buildinfo's produced<br>
> by their (re)builds of the artifacts. On top of that, I agree it'd be<br>
> helpful to<br>
> collect buildinfo's, compare them, and publish a 'reproduction report' in a<br>
> uniform way such as how you describe.<br>
<br>
The buildinfo is an output of the initial build and becomes an input for<br>
the rebuilder, but a rebuilder is always going to use the official<br>
buildinfo when verifying the official package.</blockquote><div><br></div>I don't think the buildinfo of the initial build should be a required input</div><div class="gmail_quote">for a rebuilder.</div><div class="gmail_quote"><br></div><div class="gmail_quote">The main reason we're interested in reproducible builds is that we're not</div><div class="gmail_quote">100% confident the initial build was not tampered with. Security-wise</div><div class="gmail_quote">it would be attractive when no information needs to flow from the initial build</div><div class="gmail_quote">to the reproducer.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Of course the party comparing the results needs information from both the</div><div class="gmail_quote">original builder and the rebuilder, but that might be a separate entity.</div><div class="gmail_quote">Perhaps that should even be the responsibility of the 'collector' rather</div><div class="gmail_quote">than of the rebuilder?<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Now of course I know in practice it can be logistically convenient to use the</div><div class="gmail_quote">buildinfo from the initial build as input for the rebuilder. I'm not saying we</div><div class="gmail_quote">should forbid this. But I think we should design our standards / file formats</div><div class="gmail_quote">in such a way that we do not *require* rebuilders to have access to information</div><div class="gmail_quote">from the initial build. For example, triggering a 'rebuild' whenever a new</div><div class="gmail_quote">version is tagged in source control could in some cases be a valid approach</div><div>as well.<br></div><div class="gmail_quote"><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">
> Also, I think one build can result in multiple buildinfo's, and each<br>
> buildinfo<br>
> might in turn cover multiple output files. Perhaps the 'artifacts' field<br>
> could<br>
> be layered to reflect that structure?<br>
<br>
As far as I know there's only one buildinfo output per build. In Arch<br>
Linux this file is copied into the binary packages, in debian it's<br>
published as "this is the buildinfo file for this version of this source<br>
package" that can then be used to setup the build environment that all<br>
binary packages have been built in. Please correct me if I'm wrong.<br></blockquote><div><br></div>At least on Debian, one buildinfo can cover multiple binary artifacts: for</div><div class="gmail_quote">example see the '<span class="gmail-anchor" id="gmail-line-17"></span>Checksums-Sha256' section of the example at</div><div class="gmail_quote"> <a href="https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles">https://wiki.debian.org/ReproducibleBuilds/BuildinfoFiles</a></div><div class="gmail_quote"><div><br></div><div>In my case (building JVM libraries with sbt), a multi-project build produces</div><div>a buildinfo per subproject. It might be elegant to be able to express the</div><div>reproduction of the entire build in one 'verification', but otherwise we can</div><div>publish a 'verification' for each subproject separately I guess.<br></div><div><br></div><div><br></div><div>Kind regards,</div><div><br></div><div>Arnout<br></div></div></div>