[pkg-cryptsetup-devel] cryptsetup 2.1.0-1 in sid: new default LUKS version, and more changes

[Guilhem Moulin]

Dear d-i team,

I'd like to bring your attention to the fact that cryptsetup 2.1.0-1,
which I just uploaded to sid, might affect the installer.  (While the
release has a significant changelog there was no SONAME bump, so it'll
hopefully make it to buster.)

I was able to install from a netinst ISO image to which I added the new
cryptsetup-udeb & libcryptsetup12-udeb, so hopefully no major bug will
show up.  But just so you know:

On Sat, 09 Feb 2019 at 00:34:47 +0000, Debian FTP Masters wrote:
> * New upstream release.  Highlights include:
> - The on-disk LUKS format version now defaults to LUKS2 (use `luksFormat
> --type luks1` to use LUKS1 format). Closes: #919725.

I'm glad mjg59 closed his merge request [0].  That's IMHO the kind of
change that should be done system-wise, and needs to be coordinated with
both upstream and the packaging team.  Turns out upstream had valid
reasons not to default to LUKS2, cf. the release notes for 2.0.[4-6] :-)

You might notice “WARNING: Locking directory /run/cryptsetup is missing!”
in the d-i syslog, just before the first LUKS2 device is opened.  (This
is because updates to the LUKS2 header requires multiple writes, and
atomicity is guaranteed by flock(2)'ing a file under that directory.)
The warning is harmless as the directory is created automatically (with
mode 0700) as long as its parent exists.  Of course it's always possible
to run `mkdir -m0700 /run/cryptsetup` prior to the first call to
`cryptsetup luksOpen`, like we're doing in our initramfs scripts (but
unlike for d-i, at initramfs stage the warning is annoying as it's shown
to the user before the prompt).  Failures to flock(2) immediately abort
the `open` command, so there is no risk of ending up with inconsistent
metadata here.

> - The cryptographic backend used for LUKS header processing is now libssl
> instead of libgcrypt.

Works out of the box since there is already an libssl1.1-udeb package.

> - LUKS' default key size is now 512 in XTS mode, half of which is used for
> block encryption.  XTS mode uses two internal keys, hence the previous
> default key size (256) caused AES-128 to be used for block encryption,
> while users were expecting AES-256.

`luksFormat` might cause entropy starvation on low-entropy systems that
use the default key size (i.e., don't pass `-s`) *and* use `--use-random`.
(The default RNG source for volume keys was, and still is, /dev/urandom.)
Probably irrelevant for d-i?

See

    https://tracker.debian.org/news/1028794/accepted-cryptsetup-2210-1-source-into-unstable/
    and/or
    https://salsa.debian.org/cryptsetup-team/cryptsetup/blob/v2.1.0/docs/v2.1.0-ReleaseNotes

for the full changelog.  And of course, please shout if that upload
broke anything :-)

Keep up the good work!
-- 
Guilhem.

[0] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/attachments/20190209/f8caea07/attachment.sig>