Ansgar Burchardt:
> Holger Levsen <hol...@layer-acht.org> writes:
> > together with Lunar we four sad together on the last Saturday of DebConf15 
> > in 
> > Heidelberg and discussed the next steps forward to achieve the inclusion of 
> > .buildinfo inclusion in the Debian archive and output by dpkg.
> >
> > On the ftpmaster side we agreed that:
> >
> > - dak/queued has to be changed to accept .buildinfo files
> > - will be stored on ftp-master, concatted and compressed it will be exposed 
> > to 
> > the mirrors
> >  - one per arch + suite, aka for each Packages file
>
> How large are these? I'm sure the snapshot.d.o maintainers would prefer
> something that does not change with each mirror push, or is not part of
> the dists/ tree pushed to mirrors.

Holger tested it to be about 14 MB for amd64 once compressed. This
included Arch:all packages. If we use a single tar archive, with `gzip
--rsyncable`, I assume the difference on each mirror push will be
small. But we probably could use reproducible.debian.net to come up with
actual numbers if needed.

> > - Packages file gets a certfied-by field:
> >         Build-Signed-Off-By:  0603CCFD91865C17E88D4C798382C95C29023DF9 
> > Jérémy 
> > Bobbio <lu...@debian.org> which should include the checksum of the 
> > .buildinfo 
> > file (or maybe not, see above)
> 
> I think having an external service for these is better: otherwise we
> have to deal with who can add signatures, and probably would limit it to
> people in Debian's keyring (I don't want ftp-master to deal with
> external parties).  A seperate service could accept signatures from
> everybody, including parties not directly involved in Debian or
> automated systems.
> 
> Also adding even more data to the Packages indicies is something I would
> like to avoid: the files are already quite large.

I understand the latter concern, so maybe having this information in
Packages is a bad idea and we need another index, or none as efficiency
is maybe not a problem. But I'm quite convinced that the .buildinfo
files need signatures to be any useful. With reproducible builds, we
can easily provide a trust path from the source to the binary that goes
beyond the archive signing key.

I think limiting addition of these certifications (I assert that I have
successfuly built the given binary packages with the given source in the
mentioned environment = I sign the .buildinfo) to the Debian archives to
Debian Developers is a fine thing to do. Derivatives that partially
mirror the Debian archives are free to add their own. And the tools
should also support external signature repositories.

But the Debian archive should provide signatures of the .buildinfo so
at the very least we know which buildd came up with these binary
packages in the first place.

Please note that solving the question of signatures is not strictly
needed to move “reproducible builds” forward for now. We would like to
see the changes merged in dpkg as this makes all Debian packages
unreproducible currently. And this is currently blocking on having build
information available.

-- 
Lunar                                .''`. 
lu...@debian.org                    : :Ⓐ  :  # apt-get install anarchism
                                    `. `'` 
                                      `-   

_______________________________________________
Reproducible-builds mailing list
Reproducible-builds@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/reproducible-builds

Reply via email to