[rb-general] Uploading buildinfo files to buildinfo.debian.net

[Holger Levsen]

Hi,

please note that https://buildinfos.debian.net/buildinfo-pool/ is
currently being recreated and thus not have all data again yet...

(I've added support for 3 (and more) .buildinfo files with the same
name and noticed that the numbered links were created in the wrong
order, thus the recreation.)

On Mon, Apr 29, 2019 at 10:39:30AM -0700, Vagrant Cascadian wrote:
> I really like that it provides a view in a "pool" style, e.g.:
>   https://buildinfos.debian.net/buildinfo-pool/u/u-boot/

thanks. (and me too)

> I almost wonder if we shouldn't try to coordinate archiving this data
> with:
>   https://www.softwareheritage.org/

thats an interesting idea!

> 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.

indeed.

> > 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!

yup. 

> 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.

it has them. see eg dpkg (once the pool structure is back).

> 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.

please do.

> 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
> differ, unfortunately.

the one with the correct hash for the .deb

> 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.

yes. unsigned .buildinfo files should not exist. for this to happen, as
a first step, I plan to record this state in the db (in a new table...)


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20190502/3b6f25a5/attachment.sig>