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

Patrick Schleizer adrelanos at riseup.net
Sun Sep 15 13:16:00 CEST 2019

Happy to report that both invocations of grml-debootstrap and pbuilder /
cowbuilder are compatible with mmdebstrap.

Johannes Schauer:
> you seem to claim that mmdebstrap does not support the --arch argument. But it
> does. It does so by configuring Getopt::Long with auto_abbrev. This means that
> a long option like --architectures can also be written with less characters. It
> works on my system. It does not on yours? Also from the man page:
>      Long options require a double dash and may be abbreviated to uniqueness.

Magic. :)

Works for me. :)

>> 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?

>> Not sure anymore why I added:
>> --include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
>> apt-transport-https might be required to support https repositories in
>> sources list.
> Yes, old apt versions (1.4.9 and earlier) require that package. It is since a
> dummy package.


>> apt-transport-tor might be required to support tor+https and .onion in
>> sources list.
> Yes, but mmdebstrap auto-detects tor URLs and adds the package. This behaviour
> is also documented in its man page.

Magic. :)


When mmdebstrap finished, there is still a leftover.


My apt options are good during build (apt cache etc.) but bad in the
final VM image.

Should this file be deleted?


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?



>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



> 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.


More information about the Whonix-devel mailing list