[rb-general] Comparison of the Debian and Arch .buildinfo approaches (was: Re: buildinfo filename convention)
arnout at bzzt.net
Thu Aug 9 20:32:20 CEST 2018
On Thu, Aug 9, 2018 at 7:15 PM, Eli Schwartz <eschwartz at archlinux.org> wrote:
> I'm curious what your opinion is on how Arch Linux implemented this. We
> tar up the .BUILDINFO file inside the package archive.
Thanks for the pointers, I wasn't aware of that! I'll try to summarize
my understanding here, feel free to amend ;)
The Arch .BUILDINFO is quite different (in format and fields) from the
Debian .buildinfo, though they overlap in purpose. Compare for example
the .BUILDINFO inside of
with the one shared at
The main difference is Arch includes the .BUILDINFO inside the package
and signs the whole package, where in Debian the .buildinfo is outside
of the package (but contains its hash) and is signed separately.
This means when a rebuilder successfully rebuilds in the same
environment, there is no big difference: on Arch he can share a second
signature of the same package, and on Debian he can share a second
signed .buildinfo containing the same hash.
When a rebuilder successfully rebuilds in a slightly different
environment, however, things are a little more tricky on Arch: since
the .BUILDINFO is different and contained in the package, the package
is different. This means to share a successful rebuild it is not
enough to publish a second signature, he must also share the package
he built. To check the reproduction, a checker would have to fetch
both packages and signatures, check the signatures, and check that the
packages are identical except for the .BUILDINFO file.
On Debian, it is sufficient for the rebuilder to share his signed
.buildinfo file. The checker only needs to fetch package and both
.buildinfo files, and check the signatures and hashes.
While the Arch approach has the advantage that the .BUILDINFO is more
'tied' to the package, I think I like the Debian approach more for 2
(closely related) reasons:
1) as demonstrated above, sharing and checking that the package was
successfully reproduced across 'slightly different' environments is
much easier with the Debian approach.
2) with the Arch approach, it is relatively 'expensive' to add new
fields to the .BUILDINFO, as also 'irrelevant' differences in the
.BUILDINFO lead to different packages. There is no such cost in the
Debian approach: as long as package hash in the the signed .buildinfo
is OK, all is OK. Adding (possibly-irrelevant) fields to .buildinfo
can be useful for tracking down sources of accidental
non-reproducibility, so it is nice if this is cheap.
I think there is a lot of value in checking reproducibility across
'slightly different' environments, as one of the reasons for doing
this in the first place is to find malicious sources of
unreproducibility. It would be a shame if we missed a backdoor because
we so carefully made sure all rebuilders used the same environment
(containing the same trojan).
More information about the rb-general