Buildinfo in the Debian archive, updates

[Vagrant Cascadian]

On 2016-12-07, Jonathan McDowell wrote:
> On Tue, Dec 06, 2016 at 09:24:20PM +0000, Holger Levsen wrote:
>> On Mon, Nov 14, 2016 at 02:57:00PM +0000, Ximin Luo wrote:
>> > This email is a summary of some discussions that happened after the
>> > last post to bug #763822, plus some more of my own thoughts and
>> > reasoning on the topic.
>> 
>> I think that given our last mail on this bug was >4 weeks ago, it's
>> mostly important we reply to the bug at all now…
>>  
>> > I think having the Debian FTP archive distribute unsigned buildinfo
>> > files is an OK intermediate solution, with a few tweaks:
>> > 
>> > 1. the hashes of the *signed* buildinfo files must be referred-to
>> > for each binary package, in Packages.gz
>> 
>> I actually think thats too much to ask for right now. we should
>> *propose* this now as a 2nd step, but right now the first step should
>> be that those .buildinfo files are stored *at all*, for later
>> consumption.
>
> The storage of the hashes of the signed buildinfo files in Packages.gz
> seems to be in order to deal with the fact that the signature is not
> available elsewhere.

Well, the storage of the hashes of buildinfo files in Packages is a way
to for the archive to attest "this is the exact buildinfo file used to
create this exact .deb package version on archictecture X", in the same
file it distributes information about the .deb Packages. Having a
separate Buildinfos.xz file *might* at some point be out of sync with
the Packages file (even if just due out-of-sync mirrors).

It seems (perhaps naively) like it should be cheap to add a single-line
checksum along with the Packages file, which allows users to look for
the corresponding .buildinfo (perhaps in-archive, perhaps through a
third-party service) without having to download additional
Buildinfos.xz.

I think supporting multiple buildinfo files in-archive, while nice,
shouldn't block getting the .buildinfo files used to generate the .deb
(and related) files in-archive. It's more important to distribute the
.buildinfo files in-archive that were used to build the package included
in-archive, than require an implementation supporting multiple signers.


Overall, I'm in favor of whatever incremental progress moves in the
right general direction, even if not the "perfect" direction. :)


live well,
  vagrant
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161207/7c342f9c/attachment.sig>