I wonder how elaborate their automated tests are, it is also quite interesting that the provided fix did not introduce any new tests to the codebase for the reported case.
Poettering does mention that the tests do not cover LUKS boots, and I would hope they will be adding some in the near future, but I also understand that the priority would be fix first, automated tests second (hopefully), since this is already out in the wild and in need of a fix.
Agreed, though, that full-disk encryption is common (and important) enough that it should merit good automated regression testing, especially simple "does it still boot?" tests.
I was actually amazed they don't test this scenario (I was one of first affected by this bug on all my systems about a week ago).
LUKS encryption is probably THE most common setup for newer desktop linux installations, so I was amazed they didn't test this, but just rather plain ol' unencrypted setups.
That's the wrong question, it does not matter what the default value in the distro installer partitioning step is. What matters is that LUKS (often labelled as full-disk encryption or similar) is easily available at install time, and consequently enjoys popular adoption and use.
Looks like one of the people on the thread is using Gentoo, which is one of the few distributions that offers a choice between systemd and openrc.
I currently use LUKS for full disk encryption (including /boot) on Gentoo (openrc) with Grub doing the luks unlocking (my initrd has to unlock the encrypted partition too/again, but I just have a key saved within the initrd so I don't have to type the password twice).
It sounds from the thread like Arch gives you a choice between systemd handling cryptsetup and using the older cryptsetup implementation (using shell scripts?).
If I remember correctly, systemd's native support for cryptsetup is relatively new and largely modeled on Debian's extensive integration, which worked well with systemd before the native support showed up.
No; systemd handling encrypted boot isn't new. I moved to using it over a year ago, and it was already quite spread within the Arch community (from the amount of forum posts, etc at the time), so it's probably quite older than that.
Secure Boot should be able to defend against that if you take the time to set it up (you'd need to enroll your own key in the system firmware and then sign your kernel with that key).
That is my eventual goal. I want to re-enable Secure Boot, sign my Grub EFI and place my CA (and only my CA; getting rid of the default ones) in the UEFI/BIOS settings. I think you can also embed Grub with a key to verify the kernel. (You can also just compile a kernel with UEFI Stub support, digitally sign it and have that boot directly without Grub, but I'm not sure if you can use luks that way as you still need the initrd to unlock the disk).
This would mean that if your laptop gets stolen, and you have a strong password and disable booting from other devices, the thief/fencer would need to find a way to reset the UEFI before they could install Windows on it and resell it. It's probably still possible, but it makes it much more difficult and they may just have to end up parting out the laptop and tossing the motherboard.
It feels like a step backward to be designating specific sets of files as being unworthy of encryption despite using a FDE setup.
It's also annoying to have more than one system partition to deal with when all of the pieces of software and hardware involved are perfectly capable of working normally with a single encrypted partition.
Boot is a special case to some extent as most people aren't going to care if the few files in there are readable, but then again the initrd is in there, and that could contain things that would otherwise be encrypted if they were on root.
For example, some people set up dropbear sshd in the initrd, so it's possible (even likely, depending on the tutorial being followed) that it may have a real, unencrypted copy of the sshd host key(s) the main OS would be using, once it boots. Whether you care depends on the deployment, of course.
I suspect that in some obscure cases, allowing unknown parties to see the kernel binary may count as an info leak that could be used for other attacks, potentially even against other more secure systems that happen to be running the same kernel binary.
Two distros referenced on this thread are Gentoo and Arch - both are rolling-release tinkerer's distros, and it has been noted that the feature in question has been out of scope for QA by the systemd project as of late. The community quickly found and shared workarounds and the bug will get fixed. I was bitten by this bug, but I'm not sweating it.
There's really no need to be so nasty and make personal attacks against Poettering. Please don't register a throwaway account just to throw shade, it doesn't show much class or courage.
Although it says throwaway in the username, its not actually a throwaway. Just in the same way if it said poetteringsego in the username, it would not actually be poetterings ego. Ya savvy?
