[dm-crypt] Debian installer formatting LUKS2 devices by default?

[Guilhem Moulin]

Hi there,

Debian Buster will freeze at the beginning of next year and we have
people asking for the installer to format devices with `--type luks2`.

(FWIW, I think these requests to default to `--type luks2` are mostly
motivated by a better PBKDF, so nothing impossible to obtain by
conversion from an existing LUKS1 device.)

Personally I'd rather *not* have such custom defaults in the installer.
Do you have any plan to have `luksFormat` default to LUKS2 at some
point? If so, any idea, when that would happen? ;-) Given the warning
in the latest Release Notes [0] I assume LUKS2 is not mature enough for
our installer yet. Not sure what other distros are doing, but for
Debian we're waiting for that scary warning to disappear (or
alternatively, an explicit blessing from upstream) before promoting
LUKS2 (and latter authenticated encryption — once a better AEAD
algorithm is available) in our installer and documentation :-)

Cheers,

[Milan Broz]

This post might be inappropriate. Click to display it.

[Guilhem Moulin]

Hi Milan,

Post by Milan Broz
We already added configure switch for default format, so now it is up
to the distro maintainer.

Right, but Debian is quite conservative in that regard, hence I
preferred to asked you to clarify your future plans ;-)

Post by Milan Broz
I would like to change upstream default in some next version (see below),
but we still have some issues to solve.
[…]

Thank you very much for the explanation and the very detailed roadmap!

Post by Milan Broz
The major LUKS2 fix is that libcryptsetup is now linked to libblkid
and will not automatically recover from secondary header if it detects
another (fs) signature.
(Because recovery could revert intentional change... We were too aggressive here.)
Libblkid is already used in dm/udev rules, so it should not increase
any image sizes. (And it can be disabled in configure if needed.)

I guess to you mean 8bee1a2? I hope 2.33 will be released upstream and
uploaded to Debian before the freeze.

Cheers,

[Michael Kjörling]

Post by Guilhem Moulin

Post by Milan Broz
We already added configure switch for default format, so now it is up
to the distro maintainer.

Right, but Debian is quite conservative in that regard, hence I
preferred to asked you to clarify your future plans ;-)

FWIW, I personally like Debian's conservativeness; my experience is
that it usually leads to less breakage. (It's _really_ nice to be able
to run `apt-get dist-upgrade` and generally trust that the system will
come up just fine on the next reboot.)

Obviously, there's nothing stopping whoever is installing the system
from dropping to a shell and setting up a container themselves, _even
if_ the installer _only_ does one version of on-disk format for LUKS.
So even if the installer _only_ does LUKS1, and the tools are built
with LUKS1 as default, it's not like that will _prevent_ people from
using the LUKS2 format if they really want to.

[Guilhem Moulin]

Post by Michael Kjörling
Obviously, there's nothing stopping whoever is installing the system
from dropping to a shell and setting up a container themselves, _even
if_ the installer _only_ does one version of on-disk format for LUKS.
So even if the installer _only_ does LUKS1, and the tools are built
with LUKS1 as default, it's not like that will _prevent_ people from
using the LUKS2 format if they really want to.

Sure, but now we can tell people wanting the installer to default to
LUKS2 that it'll be the new upstream default in the future, and also
give a rough ETA. It's more efficient at appeasing them than replying
they need to drop to a shell and manually format & unlock the volume :-)

[Milan Broz]

Post by Guilhem Moulin

Post by Michael Kjörling
Obviously, there's nothing stopping whoever is installing the system
from dropping to a shell and setting up a container themselves, _even
if_ the installer _only_ does one version of on-disk format for LUKS.
So even if the installer _only_ does LUKS1, and the tools are built
with LUKS1 as default, it's not like that will _prevent_ people from
using the LUKS2 format if they really want to.

Sure, but now we can tell people wanting the installer to default to
LUKS2 that it'll be the new upstream default in the future, and also
give a rough ETA. It's more efficient at appeasing them than replying
they need to drop to a shell and manually format & unlock the volume :-)

Hi,

just an update to LUKS2 as a default:

I had to postpone a plan to release 2.1 with LUKS2 as default format
(to January/February 2019), and we will release very soon 2.0.6 with some fixes
of LUKS2 format validation that need to be in place before we switch the default.

And the reason (long story):

The LUKS2 format supports variable sizes of metadata and keyslot areas,
and documentation clearly defines the supported sizes.

Cryptsetup uses validation functions that should stop reading/writing invalid header
from disk (to hit not only coding mistakes but also intentional header corruptions).

Unfortunately, we kept too strict validation in code by mistake so only default
LUKS2 header size is recognized as a valid header now.

Currently only these default headers are present (both conversion and format
create only the default size), but in 2.1 we will provide an interface to
use different LUKS2 header sizes.
And these headers will be not usable with cryptsetup older than 2.0.6.

(Larger metadata areas are requested by some other projects that plan to use
LUKS2 header for storing own metadata used for unlocking LUKS2 devices.)

IOW the format is ok. We just messed up tests and validation code. Sorry about that.

Milan

[Guilhem Moulin]

Hi Milan,
Thanks for the update! Was about to poke this thread :-)

Post by Milan Broz
I had to postpone a plan to release 2.1 with LUKS2 as default format
(to January/February 2019), and we will release very soon 2.0.6 with some fixes
of LUKS2 format validation that need to be in place before we switch the default.

I see, for Debian Buster another blocker right now is the fixed libblkid
from util-linux 2.33, although I've been told it's likely to make it for
Buster (it's in experimental right now).

FWIW, the release dates for Buster are the following [0]:

2019-01-12 Transition freeze
2019-02-12 Soft freeze (no new packages, no re-entry, 10-day migrations)
2019-03-12 Full freeze

So if 2.1 doesn't trigger a transition due to a SONAME bump, releasing
it in February gives enough time to ship it to Buster. (Strictly
speaking the deadline is March 02, assuming no RC bug is filed at the
last minute.) I guess I'll poke this thread in early February to see
where we stand.

Cheers,

[Milan Broz]

Post by Guilhem Moulin
So if 2.1 doesn't trigger a transition due to a SONAME bump, releasing
it in February gives enough time to ship it to Buster.

ok, I forget to say this: we are trying to go the way without SONAME bump now.
(IOW only adding new symbols but stay backward compatible.)

It will keep some more old API functions/symbols in place, but it allows update
without full rebuild.

Thanks,
Milan

[Milan Broz]

Post by Guilhem Moulin

Post by Milan Broz
The major LUKS2 fix is that libcryptsetup is now linked to libblkid
and will not automatically recover from secondary header if it detects
another (fs) signature.
(Because recovery could revert intentional change... We were too aggressive here.)
Libblkid is already used in dm/udev rules, so it should not increase
any image sizes. (And it can be disabled in configure if needed.)

I guess to you mean 8bee1a2? I hope 2.33 will be released upstream and
uploaded to Debian before the freeze.

Yes. It will be part of util-linux 2.33 and perhaps even stable 2.32.2.

Milan