cryptsetup 2.1 switches to LUKS2 by default

[philmmanjaro]

Describe the bug
Currently you will hit issues when cryptsetup 2.1 is not set to use luks1 still as default. grub and other bootloaders still relay on luks1 for now.

To Reproduce
Steps to reproduce the behavior:

1. Use an install media like Manjaro 18.0.3 and try to install with encryption
2. You will land in a rescue shell as grub don't support luks2 for /boot

Expected behavior
When cryptsetup 2.1 is detected, we have to use --type luks1 to explicitly use luks1 for /boot encryption until grub might adopt luks2 support.

Screenshots and Logs

Additional context
See also release notes from cryptsetup.

[kkofler]

Upstream GRUB bug: https://savannah.gnu.org/bugs/?55093

[kkofler]

I think Calamares should implement your proposed workaround for now.

[abucodonosor]

@kkofler I don't think so :-)

If you don't have grub2 with luks2 support in your Distribution then you should
build luks in your distribution with:

--with-default-luks-format=LUKS1

[philmmanjaro]

@abucodonosor: well, that is the wrong approach. We should make it possible to support luks2 for sure, however none of the key parts support that format yet. Especially grub. So CAL might be configurable and should default to luks1 for now. We can make this adjustable via config file. Just compiling cryptsetup for defaulting to luks1 might make sense, but if a distro is defaulting to luks2 we still have a problem when grub is chosen as the bootloader.

[abucodonosor]

@philmmanjaro

Yes but your bug is in packaging logic.

If you push luks with luks2 default but grub2 with luks1 default
you break on distro level already and nothing in calamares will fix that
except to workaround your installation problem.

If any of your user decide to do some kind luks setup after that all will break down
on these disks.

Quoting luks folks:

The legacy LUKS (referenced as LUKS1) will be fully supported forever
as well as a traditional and fully backward compatible format.

When upgrading a stable distribution, please use configure option
--with-default-luks-format=LUKS1 to maintain backward compatibility.

So CAL might be configurable and should default to luks1 for now. We can make this adjustable via config file.

I agree with that part we can add a luksX option in some config file until grub2
and other parts fully support luks2 key formats.

Beacuse is not only about grub2 here , but about systend generators , initramfs hooks of any sort,
dracut and probably some more.

but if a distro is defaulting to luks2 we still have a problem when grub is chosen as the bootloader.

You mean with patched grub2 for luks2 key formats() ? ..

Well we need , if we add luks2 key format(s) support to make it clear is:

1. Experimental until official support for these gets added
2. May break bc we cannot guess what Distributions may or may not patch.

and emit a 'big warning' when used.

[philmmanjaro]

@abucodonosor: grub doesn't support luks2 yet. Other software might either. However, on Arch they use cryptsetup with luks2 as default. I compiled now a version defaulting to luks1 on Manjaro. I only want to have CAL configurable and default to luks1 to avoid issues until upstream managed to get all compatible. That's all.

[kkofler]

Fedora 30 will default to LUKS 2 in cryptsetup: https://fedoraproject.org/wiki/Changes/SwitchCryptsetupDefaultToLUKS2
GRUB support for LUKS 2 will almost certainly not be there. Fedora does not care about GRUB support for LUKS because Anaconda does not use it, it sets up an unencrypted /boot instead.

[abucodonosor]

Uff and the point of having luks being then ?:) 'put your initrd into unencrypted /boot while you store your key there ' ? hmm ?

[kkofler]

Anaconda doesn't use keyfiles, you get prompted for the passphrase by Dracut rather than GRUB. (As I explained on IRC, this is what Calamares should also do if you do manual partitioning with unencrypted /boot and encrypted /. Currently, luksbootkeyfile runs in that case too, which is very broken and insecure.)

[tsimonq2]

Actually, this can easily be solved by cherry-picking the first part of this patch. It isn't in a non-beta tagged version yet, which explains why everyone's having the issue.

As it turns out, Calamares doesn't actually define LUKS2-specific partitions. It creates a partition with the Filesystem::LUKS type, which is LUKS, not LUKS2. If we wanted to do LUKS2 by default, we could certainly do that, but I would very strongly urge the maintainers to wait until both GRUB is fixed and kpmcore is tagged. The current kpmcore version, when it creates a partition with the Filesystem::LUKS type, just uses the cryptsetup default. Cherry-pick the patch, and voila.

@kkofler @philmmanjaro

[tsimonq2]

To clarify, @abucodonosor, the workaround that you ruled out has already been implemented for two years now. ;)

[abucodonosor]

@tsimonq2

please avoid to highlight or CC'ing me.

But lets clarify..

1. I don't talk about workarounds.
2. Yes this switch exists a while but you are missing the point.
3. No you cannot just cherry-pick that commit , we have to force LUKS1 like
   suggested for now.
4. LUKS2 need much more code , probably an new module
   with support for the grub* , all iniramfs/rd modules etc and at
   the same time these modules need keep
   backwards compatibility with LUKS1.
   So no it cannot be easy solved like you think it may.

Thx

[tsimonq2]

I did just cherry-pick the commit (well, pulled it downstream from Debian, thanks @highvoltage!)

You're misunderstanding what I have stated; in Calamares, when kpmcore is called, it creates filesystems with the type Filesystem::Luks and not Filesystem::Luks2. The only reason why cryptsetup updating in the first place broke this is because without the patch, which has now been cherry-picked, Filesystem::Luks is basically equivalent to Filesystem::Luks2. It's a kpmcore problem, not a Calamares one.

Easily solved. Just don't switch the kpmcore calls to LUKS2 until we have everything sorted.

Issue closed.

[highvoltage]

In debian I patched kpmcore to specify --luks1 when configuring the encryption containers. I believe the correct place to fix this is in kpmcore, not calamares. kpmcore should have an option to specify whether you want to configure luks1 or luks2, then you can have that as an option in calamares.

[abucodonosor]

@highvoltage

no , In both not only kpmcore or calamares.

While is fine kpmcore to have a API for both , calamares need implement
LUKS1 && LUKS2 in his modules and options for the Distros.

Is not only about force LUKS1 or LUKS2 because that won't work with the code
exists now in calamares. ( OK LUKS1 ofc does but LUKS2 ).

Also kpmcore is not the right place to force what calamares may need.
Calamares itself need be in control based on configuration options.

[highvoltage]

@highvoltage

no , In both not only kpmcore or calamares.

While is fine kpmcore to have a API for both , calamares need implement
LUKS1 && LUKS2 in his modules and options for the Distros.

Is not only about force LUKS1 or LUKS2 because that won't work with the code
exists now in calamares. ( OK LUKS1 ofc does but LUKS2 ).

Also kpmcore is not the right place to force what calamares may need.
Calamares itself need be in control based on configuration options.

@abucodonosor I think you may have misunderstood me.

[pepa65]

A LUKS1 container should only be made when the boot-files are in that particular container and the version of Grub installed is not able to handle LUKS2, that would be the best way to future-proof.

Whenever Grub is able to handle LUKS2, this provision can be removed.

If Calamares is going to make this decision, then the way different distros handle the situation is circumvented.

[kkofler]

And how do you propose we detect whether GRUB supports LUKS2?

[pepa65]

Probably by querying the version?

[abucodonosor]

Not possible. It can be a custom patch, snapshot or whatever. Or someone just doesn't want that support.

[kkofler]

Exactly, plus we also do not know what version of GRUB will support LUKS2 because there is no such version at this time.

[pepa65]

Do what you think is best, I prefer not to use Grub at all myself.
But once you know Grub does support LUKS2 you update your application and you'll be serving the people that do want to use Grub in the best way possible.
Once you force LUKS1 usage when it's not necessary, you're doing a disservice to your users.

[scottAnselmo]

Grub now supports LUKS2: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=365e0cc3e7e44151c14dd29514c2f870b49f9755

So is it the case that a feature request/issue needs to be created to ask for Calamares to now use LUKS2 by default (assuming it was switched to LUKS1 at some point) and package with the new grub bootloader?

[abucodonosor]

It is not how is working. That commit exists in git and even it would exist on some released grub2 package we still cannot switch that now until distros ( mostly LTS ones ) move to newer grub2 packages. Also, I don't think we can switch that at all to LUKS2 for a longer time, but have a Luks2 module of some sort and use a configuration option to switch the code is used.

[kkofler]

I think we just need an option

luks2:    false

which would be false by default at least until the patched GRUB is more widespread, but which distros already shipping it could set to true if desired.

[kkofler]

Be warned that even with current GRUB master, you still need a workaround CLI flag to cryptsetup to get something that GRUB understands!

GRUB master only supports LUKS2 with PBKDF2 as the PBKDF (the same PBKDF used by LUKS 1) (see [GRUB commit 365e0cc]):

Note though that in the current version, only the PBKDF2 key derival function is supported. This can mostly attributed to the fact that the libgcrypt library currently has no support for either Argon2i or Argon2id, which are the remaining KDFs supported by LUKS2. It wouldn't have been much of a problem to bundle those algorithms with GRUB itself, but it was decided against that in order to keep down the number of patches required for initial LUKS2 support. Adding it in the future would be trivial, given that the code structure is already in place.

but the default PBKDF for LUKS2 is actually argon2i (see [cryptsetup configure.ac#L578]). So you still need a cryptsetup CLI flag (--pbkdf=pbkdf2, see [cryptsetup.8#L1055]) to work around it.

[kkofler]

Also note that forcing PBKDF2 actually nullifies one of the two purported advantages of LUKS2, so I am not convinced that it is worth jumping the gun on LUKS2 just now. IMHO, it makes more sense to wait for full GRUB support including Argon2i and to default to LUKS1 for now.

[jtheoof]

You can have a look at #2047 and #2070. Luks2 is now supported if maintainers activate it.

[kkofler]

KPMCore has been passing --type luks1 for the partition type luks (as opposed to luks2) for 4 years now:
https://invent.kde.org/system/kpmcore/-/commit/1802b7ad05d22b24b74c9b14abcdbf421d00140f
so this bug is fixed (assuming you use a recent enough KPMcore, but it is an upstream KPMcore issue in any case).

In addition, the related wish to support LUKS 2 as an option is implemented by #2047.

Hence, closing this bug.