Buildinfo in the Debian archive, updates

[Jonathan McDowell]

On Wed, Dec 07, 2016 at 11:00:00AM +0000, Ximin Luo wrote:
> Jonathan McDowell:
> > I was under the impression that each set of binary artefacts from a
> > build would be accompanied by a single buildinfo file describing the
> > environment used. This would be signed by the original uploader, and
> > then there would be the possibility of further people attesting to
> > that pairing of buildinfo + binaries, rather than providing an
> > entirely separate set of buildinfo (+sig) information that produces
> > the same binary.
> > 
> > Is there a requirement that the archive is capable of storing
> > multiple buildinfo files, rather than just multiple buildinfo
> > signatures, for a given set of binary artefacts?
> > 
> 
> Yes, buildinfo files are expected to be different, even for multiple
> builders that successfully reproduced the same binary hashes. The
> Binary: fields would be the same, but the other fields might be
> different. This is a good thing from a security perspective.
> 
> For more details on why you can read the draft here:
> 
> https://anonscm.debian.org/cgit/reproducible/buildinfo-spec.git/tree/notes/buildinfo.rst

My reading of that is that ideally buildinfo files would describe T, the
minimal information required to rebuild reproducibly. However
limitations in knowing exactly what T is for a particular package mean
that you currently record U', a superset of T, and that by recording
multiple of these you hope to be able to converge towards T.

I'm not sure this argues for being able to support multiple sets of
buildinfo information for a single set of binary artefacts within the
context of the Debian archive.

J.

-- 
Is this real - that's the first thing I think every morning.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/reproducible-builds/attachments/20161207/6b0be5ff/attachment.sig>