Reproducible Builds Verification Format
kpcyrd
kpcyrd at rxv.cc
Thu May 14 12:37:03 UTC 2020
On Thu, May 14, 2020 at 02:10:04PM +0200, Marek Marczykowski-Górecki wrote:
> > This is an implementation detail, isn't it? A buildinfo wouldn't be required if
> > you are in an environment where the build environment doesn't change. But in
> > many cases, this isn't the case. Dependencies we pulled could have new versions
> > which could very well interfer with the build. And if we don't have the
> > buildinfo file at hand, how would we know what introduced the change?
>
> The discussion is about build verification format, not rebuilder
> architecture specifically. I think what this format should represent is
> a simple info to be consumed be for example package manager:
The argument was that a debian/arch rebuilder *always* needs to take the
buildinfo file as a rebuild input. That's the reason the buildinfo is
shipped inside the arch package, collecting detached buildinfo files is
a debian thing, but only the buildinfo file for the build that was
actually uploaded into the archive is useful for anything.
> I have built package <X>, version <Y>, with source hash <AAA> and
> got binary package(s) <BBB> with hash <CCC>.
> -- signed by (re)builder <RRR>
>
> Other information, like what rebuilder needs to know, or what
> environment was used etc could be optional, or even totally separate.
> And in fact, we do have a format for that extra info already: buildinfo
> file. And I think that should be kept separated.
>
> In fact, for the sole verification purpose, IMO just source hash should
> be enough (if we trust the hash we use), but for debugging purposes it
> may be convenient to name the package and version anyway.
You can't assume the package manager knows about the source since their
view of the world is often just the list of binary packages, not the
source they've been built from.
There's no question what environment was used to rebuild: the one
described in the official buildinfo file, so I think recording it would
be redundant.
More information about the rb-general
mailing list