[rb-general] offical Debian docker images reproducible? (Re: Reproducible system images)

[Holger Levsen]

On Wed, Jan 29, 2020 at 01:35:13PM -0800, Tianon Gravi wrote:
> I'd personally be happy to see more of this as part of debootstrap
> itself, but from what I've seen debootstrap isn't very actively
> maintained these days (which is understandable, given that for the
> purposes of things like d-i, it "just works", and any changes in it
> tend to have somewhat of a ripple effect).
> 
> I'm also excited about / interested in what projects like mmdebstrap
> can offer, so will be watching that space (and really d-i in general).

I've been starting to switch the jenkins.d.n code to use mmdebstrap
where possible and it mostly has been a pleasant switch.

just
https://jenkins.debian.net/view/reproducible/view/Debian_setup_amd64/job/reproducible_setup_schroot_unstable_diffoscope_amd64_osuosl172/
is currently broken as this host is running in the future, so I suspect
mmdebstrap need to be told to ignore expired certificates...

(hints welcome ;)

> > Right now I'm now quite sure, where we (r-b.o) should promote them, eg on
> > https://reproducible-builds.org/who/#Debian or better create
> > https://reproducible-builds.org/who/#Docker? Or only on
> > https://wiki.debian.org/ReproducibleBuilds?
> We'd be flattered with any reference to it, but it's built upon/only
> possible thanks to the work of y'all anyhow! :)

Tianon, I'd be glad to merge patches for
https://salsa.debian.org/reproducible-builds/reproducible-website/
and probably best for both https://reproducible-builds.org/who/#Debian
and https://reproducible-builds.org/who/#Docker ;)

> > Then upon reading https://hub.docker.com/_/debian/ I miss:
> >  - checksums of the images
> >  - instructions how to recreate those images (eg which SOURCE_DATE_EPOCH
> >    was used)
> 
> For me, the fact that Holger's asking these questions is a sign we
> need to a better job explaining what we mean in the image description,
> so to that end I've got
> https://github.com/docker-library/docs/pull/1633 open and would really
> love any feedback anyone from this list might have on how it could be
> improved. :)

thanks. looks good / better to me.

> I hope that docs PR clarifies reasonably, but it might also help to
> add this bit of color I included in a private reply to Holger (paultag
> took the conversation off-list to clarify something else and I'd
> replied there):
> 
> > As for hashes, I think that's a bit more complicated.  We don't
> > maintain either directly on that image description because we'd have
> > to have an explicit "update the hashes" PR to
> > https://github.com/docker-library/docs for every image update, which
> > is hopefully understandably not something we're interested in doing
> > (and would be disruptive for more than just us).  Some of that can be
> > gleaned from "docker image inspect xxx", which then has a content
> > digest, but by the time that digest is generated it's round-tripped
> > through a Docker graph driver, and I'm not 100% sure they all can
> > handle full reproducibility (AUFS, btrfs, devmapper, etc).

I think it would still be good to record the hashes somewhere reliably.
How about in another git repository?

> > What I mean when I say the images are reproducible, is that the
> > "rootfs.tar.xz" has been reproducible, which you can find a hash for
> > in that same directory referenced above (per published tag) under
> > "rootfs.tar.xz.sha256" ([2] for example).  It will also be relevant to
> > take "rootfs.debuerreotype-version" into account, because the
> > reproducibility of a given tarball has traditionally been dependent on
> > the version of debuerreotype (sometimes we have no choice but to make
> > a hash-breaking change, sometimes it's for the "greater good" like
> > adding more clues in the images themselves for traceability, such as
> > those provenance comments in "sources.list").

yes, that's what we collect in .buildinfo files...

> Maybe this is already explained reasonably in my PR, or maybe I need
> to expand on it there?

i think merging this PR now would be a good step in the right direction,
not blocking further improvements later. ;)

> Thank you all for your work on reproducible builds! :D

thank you too! :)


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20200130/2e19ced6/attachment.sig>