source-only builds and .buildinfo

Ximin Luo infinity0 at debian.org
Wed Jun 21 09:28:00 UTC 2017


Adrian Bunk:
> On Tue, Jun 20, 2017 at 02:47:20PM -0400, Daniel Kahn Gillmor wrote:
>> Hi Ian--
>>
>> On Tue 2017-06-20 18:10:49 +0100, Ian Jackson wrote:
>>> A .buildinfo file is not useful for a source-only upload which is
>>> veried to be identical to the intended source as present in the
>>> uploader's version control (eg, by the use of dgit).
>>>
>>> Therefore, dgit should not include .buildinfos in source-only uploads
>>> it performs.  If dgit sees that a lower-layer tool like
>>> dpkg-buildpackage provided a .buildinfo for a source-only upload, dgit
>>> should strip it out of .changes.
>>
>> I often do source-only uploads which include the .buildinfo.
>>
>> I do source-only uploads because i don't want the binaries built on my
>> own personal infrastructure to reach the public.  But i want to upload
>> the .buildinfo because i want to provide a corroboration of what i
>> *expect* the buildds to produce.
>> ...
> 
> If you expect that, then your expectation is incorrect.
> 
> If you upload a package right now, chances are the buildds will use both 
> older versions of some packages [1] and more recent versions of some 
> other packages [2] than what you used.
> 

I think what dkg means here (and what we the R-B team has wanted for ages and is working towards), is not that the buildds use the *versioned dependencies* listed in the buildinfo, but produce the same *output hashes* as what's in the buildinfo.

The point being specifically that the dependencies used could change, but if the output remains constant, we're more assured that the build was done properly and reproducibly.

X

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



More information about the Reproducible-builds mailing list