Buildinfo in the Debian archive, updates

[Ximin Luo]

Jonathan McDowell:
> [..]
> 
> 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. If dkg's suggestion of using ECC signatures is
> followed then some quick checking shows a signature size of 165 bytes
> (when ASCII armoured). This seems sufficiently small to me that you
> could just map it into a Signature: field at the end of the buildinfo
> stanza within buildinfo.xz, with the bonus that at some point that would
> allow for multiple such fields, all within the archive mirror network.
> The max permitted size of such a field could be something configurable
> by ftp-master, so if that they wanted to allow full RSA based signatures
> they could set it to ~800 bytes, or limit it to ECC at < 200 bytes.
> 

Daniel Kahn Gillmor:
> On Wed 2016-12-07 06:31:00 -0500, Ximin Luo wrote:
>> Separately regarding the ECC point, I don't think we can assume that
>> at this time because DDs still have non-ECC signatures, and are still
>> doing binary uploads with buildinfo files that we want to store.
> 
> sure, but that's just one buildinfo file per package, compared to N
> buildinfo files for the build daemons on N different architectures.  We
> can certainly give all the buildd's ECC keys if we're concerned about
> size in the archive.
> 

To put this in context, what I meant was simply that the Signature: field Jonathan proposed should initially support RSA-4096 signatures (800 bytes) as well.

This would be about (800 - 165) * 24000 / 1048576.0 ~= 14.53MB extra for the -amd64 and -all Buildinfos, which isn't so bad.

If we go down this route (and it's looking pretty good IMO) then I agree that we don't need to store the binary hashes in Packages.gz. But we should store a hash of each Buildinfos.xz in the Release files (that are signed), so there is a cryptographic "route" from what is signed by Debian, to what is signed by the builders.

Are you all coming to the meeting next week? We should figure out some way to divide up this work. I'm not very familiar with the dak code atm, some pointers would be nice.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git