source-only builds and .buildinfo

[Adrian Bunk]

On Wed, Jun 21, 2017 at 10:09:00AM +0000, Ximin Luo wrote:
> Adrian Bunk:
> > On Wed, Jun 21, 2017 at 09:28:00AM +0000, Ximin Luo wrote:
> >> 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.
> > 
> > How is that supposed to work when the compiler is not exactly identical?
> > 
> > As an example, gcc-6 6.3.0-18 and gcc-6 6.3.0-19 will likely produce 
> > different output for every non-trivial piece of software.
> > 
> > The reason is that every new gcc upload usually contains whatever 
> > bugfixes are on the upstream branch.
> > 
> 
> It would depend on the situation which dependencies should be "irrelevant" towards the final output, right. If the dependencies are different and the buildinfo is different, it does not necessarily mean there is a problem, the upload does not need to be rejected. But it's a signal that other people (including the uploader) might want to re-try the build with the newer dependencies.
> 
> OTOH if the outputs match, we get more certainty, which is a good thing.
>...

"more certainty" on what exactly?

"signal that other people might want to" is quite vague,
what do you want to prove and how exactly should people
spend time proving it?

In the best case [1] we would know that the buildd on the one 
architecture that happens to be used by the person doing the
source upload produced the same binaries.

Once you start verifying that all binaries in the archive were built 
from the sources in the archive, this will automatically be covered.

> X

cu
Adrian

[1] excluding the binary-all special case

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed