Bug#927165: debian-installer: improve support for LUKS

[Cyril Brulebois]

Package: debian-installer
Version: 20190410
Severity: important

[ Copy sent to grub2 and cryptsetup maintainers, in addition to
debian-boot@ who maintains debian-installer; please keep everyone in
copy when answering. ]


This bug report serves as an entry point from the d-i errata page[1].
It is likely that some topics discussed below will be split into their
own separate bug reports.

 1. https://www.debian.org/devel/debian-installer/errata


In version 2:2.1.0-1, cryptsetup change the default on-disk LUKS format
from luks1 to luks2[2].

 2. https://tracker.debian.org/news/1028794/accepted-cryptsetup-2210-1-source-into-unstable/

There are also some other highlights in this changelog entry, regarding
key sizes, and some update to partman-crypto might be needed…


Some direct consequences of this default format change:
 - slightly anecdotal: stretch's d-i cannot rescue an encrypted buster
   system, as it doesn't know how to deal with this format;
 - but more worrisome: grub currently has no support for LUKS2. This
   means that users who want to use GRUB_ENABLE_CRYPTODISK and avoid a
   separate, unencrypted /boot, won't be able to do so…

I've only learned about this today, thanks to Colin Watson who brought
it up when I was asking for feedback when preparing D-I Buster RC 1.


Now the question is: What can be done in time for buster?

 - It seems unlikely to have LUKS2 code ready for grub.
 - It should be feasible to add an option to force LUKS1 when
   installing. Having a question asked in expert mode should do the
   trick, and one could preseed that setting from the kernel command
   line to avoid having to use expert mode all the way.
 - We should probably document (e.g. in the installation guide and/or
   crossreferenced from release notes) the “GRUB_ENABLE_CRYPTODISK vs.
   LUKS2” incompatibility and the above setting once it's implemented.


One could argue that cryptodisk support has never been supported by d-i
anyway, but some users seem to have grown their own tricks/recipes to
install with this feature anyway, so we really need to try our best to
get that documented at the very least, and to have some workaround put
in place.


And for those who would wonder: It seems that LUKS2 brings some
interesting features on the security front, so it doesn't seem really
reasonable to stick to LUKS1 unconditionally.


Cheers,
-- 
Cyril Brulebois (kibi at debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant