[rb-general] Uploading buildinfo files to buildinfo.debian.net
vagrant at reproducible-builds.org
Mon Apr 29 19:39:30 CEST 2019
On 2019-04-29, Holger Levsen wrote:
> On Fri, Feb 15, 2019 at 01:51:40PM -0800, Vagrant Cascadian wrote:
>> On 2019-02-15, Holger Levsen wrote:
> we now have two similar implementations of a buildinfo server for Debian
> .buildinfo files:
> - https://buildinfo.debian.net - this service exists since Oct. 2016
> - https://buildinfos.debian.net - this service exist since March 2019
I really like that it provides a view in a "pool" style, e.g.:
I almost wonder if we shouldn't try to coordinate archiving this data
It might be a slight stretch of their mission to call .buildinfo files
"source code" ... but I wouldn't mind making the case that .buildinfo
files should be considered source code.
>> The vast majority of buildinfo files uploaded to the archive should be
>> present in buildinfo.debian.net since November 2018. I also "manually"
>> uploaded all the available buildinfo files from 2017-2018 (most of the
>> very small number from 2016 failed for one reason or another).
> buildinfos.debian.net has all .buildinfo files since December 2016.
Very cool! It is definitely a much simpler approach and catches many
corner cases (unsigned, signatures, etc.) that my method doesn't!
It seems to be missing the .buildinfo.N, which in some cases are the
actual .buildinfo files built by the buildd's and the corresponding .deb
files shipped in the archive.
The .buildinfo without a numbered increment is frequently provided by
developers who follow best practices and do source-only uploads that
include a signed .buildinfo file. I'll take a look at the code and see
if I can't propose a simple fix.
The presence of multiple .buildinfo* files does make it harder to know
which .buildinfo to use to reproduce a build from the archive if they
>> There are a few individual developers uploading unsigned .buildinfo
>> files, as well as a few buildds for non-release architectures
>> (e.g. hurd-i386, kfreebsd-*). To hadle those, I actually had a
>> legitimate use for the technique described in:
>> Which basically means I don't even bother attempting to upload unsigned
>> buildinfo files.
> see above :) (=buildinfos.d.n has those.)
Unsigned .buildinfo files are of limited usefulness, if we're really
trying to establish a chain of verification... though perhaps it's still
better than no .buildinfo at all, since the archive verifies the
.changes file before including it... though obviously a compromised
archive could inject malicious unsigned .buildinfo files more easily and
requires some trust needed in specific parties.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 227 bytes
Desc: not available
More information about the rb-general