[Whonix-devel] Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

Sun Sep 15 14:18:56 CEST 2019

Quoting Patrick Schleizer (2019-09-15 13:16:00)
> Happy to report that both invocations of grml-debootstrap and pbuilder /
> cowbuilder are compatible with mmdebstrap.

Cool!

> >> Using a file
> >> /home/user/Whonix/build_sources/debian_stable_current_clearnet.list which
> >> contains both, Debian "standard" repository as well as Debian security
> >> repository.
> >>
> >> This is to make use of mmdebstrap excellent security feature to
> >> bootstrap from two repositories at once. If the APT version in Debian
> >> "standard" repository had a vulnerability, then the vulnerable version
> >> would be installed first before vulnerable APT would be used to upgrade
> >> in a later step from Debian security repository.
> >>
> >> "Incompatibility" is perhaps a far stretched term. How do we "teach"
> >> grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
> >> repository and Debian security repository when using mmdebstrap"?
> >>
> >> It's like "the ecosystem does not take advantage of mmdebstrap" yet.
> > 
> > Okay, but as far as I can see there is nothing that can be done in mmdebstrap
> > about this, right?
> Maybe not.
> 
> I guess the problem indeed isn't mmdebstrap but how other tools are
> invoking $DEBOOTSTRAP.
> 
> Do you think you could contact pbuilder / cowbuilder / grml-debootstrap
> to see how invocation of debootstrap (single repository) vs mmdebstrap
> (Debian "standard" repository + Debian security repository) invocation
> could be sorted out?
> 
> Not sure how crazy would it be to have mmdebstrap auto inject the Debian
> security repository? Perhaps keep mmdebstrap as is but have a wrapper
> mmdebstrap-sec-repo (or so) that injects it?

Maybe I'm not understanding the problem yet. Mmdebstrap currently does
automatically inject the updates and security mirrors if you specify "stable"
or a stable release name on the command line. If you specify a sources.list
file, then it will not do so automatically because then presumably you want to
take full control yourself. Why would you want a wrapper? Do you need to create
your own sources.list file? Why?

> #####
> 
> When mmdebstrap finished, there is still a leftover.
> 
> /etc/apt/apt.conf.d/99mmdebstrap
> 
> My apt options are good during build (apt cache etc.) but bad in the
> final VM image.
> 
> Should this file be deleted?

You probably added some custom --aptopt options in your mmdebstrap invocation?
That file contains all your custom options. Are you suggesting to name that
file differently? If you delete that file, then you also loose the apt options
you passed.

> #####
> 
> mmdebstrap fails when /etc/hostname is missing. An empty /etc/hostname
> works for me. Sometimes it's not wanted to leak any host files into the
> folder (reproducible builds, privacy, and whatnot). Could you please
> have mmdebstrap handle non-existing /etc/hostname (and other system
> files (/etc/host /etc/resolv.conf?) gracefully?

That's a very good point! I pushed a new commit which will only copy
/etc/hostname and /etc/resolv.conf if they exist. /etc/host isn't used.

> #####
> 
> minor:
> 
> From home folder (in a Qubes Debian VM):
> 
> ./mmdebstrap --include=apt --variant=buildd --force-check-gpg buster
> ./test https://deb.debian.org/debian
> 
> I: The option --force-check-gpg is a no-op. It only exists for
> compatibility with some debootstrap wrappers.
> I: automatically chosen mode: unshare
> I: chroot architecture amd64 is equal to the host's architecture
> mkdir /home/user/test: Permission denied at ./mmdebstrap line 992.
> 
> ls -la
> 
> drwxr-xr-x  2 100000 100000   4096 Sep 15 06:07 test

This is weird. Resolving this could be more complex. I suspect some weird
interaction between your VM and unshare. Maybe you should open a specific bug
about this issue because I need to know more details.

> #####
> 
> minor:
> 
> > I: The option --force-check-gpg is a no-op. It only exists for
> compatibility with some debootstrap wrappers.
> 
> 
> Not sure that implies insecurity. I know gpg signatures are verified but
> could confuse others. Perhaps just drop that option from output. Keep it
> in man page / command line help only. Users / wrappers using
> --force-check-gpg get what they expect anyhow. No need to notify.

I don't understand where the confusion is here? Could you elaborate?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://www.whonix.org/pipermail/whonix-devel/attachments/20190915/722a3166/attachment.sig>