Control: unblock -1 by 944729 Hi Guilhem,
thanks for your very helpful review! Quoting Guilhem Moulin (2019-08-16 14:45:17) > On Wed, 14 Aug 2019 at 14:54:08 +0200, Johannes 'josch' Schauer wrote: > > when I upgraded my Squeeze box to Jessie, remote unlocking via dropbear > > in my initramfs stopped working. This is a remote host in a datacenter, > > so I cannot directly investigate the issue. > Interesting, once you manage to boot I'd be interested to know the > reason. Also FWIW I also use remote unlocking via dropbear on > production systems, and my setups have survived all upgrade paths, incl. > Squeeze → Jessie. And AFAICT you're the first to report a breakage at > dist-upgrade stage, so I'm not entirely convinced this would have been > caught by a simple autopkgtest :-P Indeed it would not. The autopkgtest does not even test upgrades. But when I re-installed the system after the upgrade failed I also was unsure in many points of how to do it correctly. The autopkgtest does not only serve as a constant assurance that the current state does work but also serves as documentation of which knobs have to be turned to successfully set it up. It can thus serve as an addition to /usr/share/doc/dropbear-initramfs/README.Debian > Oh wait, you upgraded from Squeeze to Jessie via Wheezy, right? > Directly upgrading from Squeeze to Jessie is not a supported upgrade > path. No, I always only upgraded foo to foo+1. It doesn't matter now because the situation is fixed and I could not've investigated anyways because I have no way to observe the boot process. > > If you like the script, then I could prepare a patch against src:dropbear > > which implements an autopkgtest that runs the script. > Can't hurt indeed, thanks! A few comments inlined below. Thanks, those were very helpful. > > pkgs="linux-image-amd64,openssh-server,systemd-sysv,libpam-systemd,policykit-1" > > pkgs="$pkgs,iproute2,util-linux,e2fsprogs,ifupdown,net-tools,netbase" > > pkgs="$pkgs,iputils-ping,isc-dhcp-client,lvm2,parted,cryptsetup" > > pkgs="$pkgs,dropbear-initramfs,busybox,fdisk,mmdebstrap,udev" > > If you include ‘dropbear-initramfs’ I guess you want ‘cryptsetup-initramfs’ > not ‘cryptsetup’. Yes. cryptsetup is only required on the system setting up the encrypted disks (but cryptsetup-initramfs is not needed there) and cryptsetup-initramfs is required on the system with the encrypted disks (but cryptsetup is not needed there). Fixed. > Also AFAICT ‘iputils-ping’, ‘parted’ and ‘busybox’ are not needed (the latter > will be pulled by ‘cryptsetup-initramfs’ and ‘dropbear-initramfs’). Yes. All removed. Those were leftovers from when I was testing the whole thing and I didn't clean up the packages yet. I removed a few more things now. > > auto ens3 > Is the interface name reliable? I was under the impression it wasn't because > it depends on how QEMU arranges its devices, unlike the use of ‘eth0’ after > adding ‘net.ifnames=0’ to the kernel cmdline. Yes. The interface name is not reliable under qemu unless (I guess) you manually add the network card on a certain interface. Otherwise it might break on the next qemu update when the defaults change. I now use eth0 and net.ifnames=0 instead. > > qemu-img convert -O qcow2 debian-unstable.img debian-unstable.qcow2 > The conversion from raw to qcow2 format is not needed, is it? Correct. Removed. > > qemu-system-x86_64 -enable-kvm -m 4G -net user,hostfwd=tcp::10022-:22 \ > 4GiB sounds really overkill here, surely 1GiB is enough? This is what I use > for testing the various device stacks before src:cryptsetup uploads. Yes, 1G is sufficient. Fixed. > I'd also bind to INADDR_LOOPBACK, change the NIC and drive model from the > default (resp. e1000 and ide) to virtio, and pass `-no-user-config > -nodefaults`. Maybe also set the CPU model to host. Might also help to > create a virtio-rng device, given that key material is generated on the > guest. I'm unsure about -no-user-config -nodefaults. This will require a much larger command line for what benefit? What benefit would changing the nic and drive to virtio have? Sorry, I'm not an expert on this. :) Yes, adding something like this might be useful: -object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0 I'll benchmark this to see whether there is a noticeable difference. > > printf myinsecurepassphrase | cryptsetup luksFormat /dev/sdb3 - > To speep up things I suggest to skip the the PBKDF benchmark by passing > `--pbkdf-force-iterations 4 --pbkdf-memory 32` (for Argon2), or > `--pbkdf-force-iterations 1000` (for PBKDF2). cryptsetup <2.0 (up to > Stretch) are only able to format and open LUKSv1 volumes, which only > supports PBKDF2 as PBKDF algorithm; since cryptsetup 2.0 a new LUKS > version format is available (and is the default as for Buster) with > support for both Argon2i/d (default) and PBKDF2. Is this only for a potential speedup? Is it not better to test the default setup? > > cat > "/mnt/etc/initramfs-tools/conf.d/dropbear" << END > > IP=":::::ens3:dhcp" > > END > AFAICT it's redundant since you have the same thing as boot parameter. I wasn't aware that either works. I guess I will use /etc/initramfs-tools/conf.d/dropbear and not the boot parameter so that the former gets the testing. > > chroot "/mnt" apt-get -y install lvm2 grub2 linux-image-amd64 openssl > > cryptsetup dropbear-initramfs busybox udev mount systemd-sysv util-linux > > e2fsprogs initramfs-tools cryptsetup-initramfs cryptsetup-run console-setup > > openssh-server ifupdown net-tools netbase iproute2 libpam-systemd > > policykit-1 iputils-ping isc-dhcp-client > Some of these are redundant, and might not be marked as manually > installed on a normal installation. ‘cryptsetup-run’, ‘busybox’, > ‘initramfs-tools’ at least. Yes. Deleted. You can see the current job running here: https://salsa.debian.org/josch/dropbear/-/jobs I'm tinkering more with it to remove some more rough edges. Comments welcome! Thanks! cheers, josch
signature.asc
Description: signature
