[rb-general] Core Debian reproducibility: how close?

[Holger Levsen]

Hi David,

your simple question is not that simple... :)

On Wed, Oct 24, 2018 at 10:42:08PM -0400, David A. Wheeler wrote:
> > > If there's an estimated time of arrival that'd be awesome... is
> > > there one?
> > As I am sure you are aware Debian doesn't, generally speaking, work
> > on that sort of timeline basis. "As soon as possible", "yesterday",
> > "when it's ready", etc. etc.
> That was the answer I was *expecting*, just not the one I was *hoping* for :-).
 
besides what Chris said, I think it's useful to divide your question
into several:

when will we have:
- reproducible debootstrap?
- reproducible installer build?
- reproducible installation images?
- reproducible default desktop installation?
- reproducible cloud images?
- all packages in Debian reproducible?

And then it will need up to two years to go from sid to stable :)

For "reproducible debootstrap" I believe the answer could be 2018 or
2019. Sadly the best status page I know is https://wiki.debian.org/ReproducibleInstalls
and that was last edited in 2017.

For "reproducible installer build" I have to admit I have no idea.

For "reproducible installation images", TAILS has shown this can be done
today. Someone "just" needs to check the debian images and adopt the
changes done in TAILS.

For "reproducible default desktop installation" we really should have
an exact matching package set on https://tests.reproducible-builds.org/debian/buster/amd64/index_pkg_sets.html
but until the the 30 failing packages on
https://tests.reproducible-builds.org/debian/buster/amd64/pkg_set_gnome.html
are giving a good idea.

For "reproducible cloud images" I have just asked #debian-cloud to give
me a list of packages so I can setup another package set to track...

For "when will all packages in Debian be reproducible" I have just added
another big outstanding issue to https://wiki.debian.org/ReproducibleBuilds/
which is: “currently debian-policy says "packages should be reproducible", 
though we aim for "packages must be reproducible" though it's still a long
road until we'll be there: currently (Oct 2018) there are more than 1250
unreproducible packages in Buster, thus if policy would be changed today,
1250 packages would need to be kicked out of Buster (well, or fixed) immediatly,
so this policy change right now is not feasable.“

So, my guess/hope is that by 2020-2021 we can make this policy change and
then only kick 3-500 packages out *and* ignore 23-42 policy violations,
because there will be some packages we cannot kick out, but we (Debian)
will still want to change policy to a 'must', hopefully.


This is all while ignoring build path variations (which are dead simple
to ignore by not varying the path) and also ignoring the problems
Vagrant mentioned about .buildinfo files and whatnot. I will reply to
those aspects in another mail in this thread. (Just writing this email
took much longer than expected already.)

I believe it's useful to file 6 bugs to track those 6 topics and I will
do so in a bit. I *don't* think it's useful to file a bug against policy
now, asking for the 'must-change' now.

> > > Also, one of those items looks more like a "future nice to have"
> > > than something necessary to counter subverted binaries
> > Sounds about right; fancy updating the wiki to match? Thanks.
> Done.  I modified "Big outstanding issues" by moving several items to a new section
> "Nice to have".  If it's not right, please fix away!!
 
Thank you for this and also for starting this thread in the first
place!

> > > It might be better to primarily focus efforts on getting the reproducible
> > > builds for the core packages actually used by people.  Perhaps that's
> > > already happening, it's not clear to me just from following the mailing
> > > list.

this is either not so easy (as explained above) and/or we are already
doing this: https://tests.reproducible-builds.org/debian/buster/amd64/pkg_set_popcon_top1337-installed-sources.html

what's missing, especially lately has been any focus on those 59
packages failing there (or focus on anything...) (could partly be
related to lack of funding...)

> My email may have come off harshly, and I didn't mean it that way.

understood. (and I didnt perceive your email that way.)

> I'm a big fan of the reproducible build effort.  My concern is that
> there is a real need for reproducible builds to get to users... the sooner, the better!

definitly.

it's just a very big challenge: the stuff I described in this email is
mostly what I call the theorectical side of reproducible builds (making
sure the software can be build reproducible) while I havent really
touched the practical parts (how to make sure distros have reproducible
builds which can be verified by users) I havent mentioned at all,
basically. 

I will get to that (Vagrant started this subthread nicely) in a bit,
though I'm not sure this will be today.


-- 
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/20181025/bcd600ef/attachment.sig>