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