[pkg-cryptsetup-devel] Upcoming transition: libcryptsetup4 -> libcryptsetup12

[Guilhem Moulin]

On Sun, 17 Dec 2017 at 18:12:21 +0100, Cyril Brulebois wrote:
> Guilhem Moulin <guilhem at debian.org> (2017-12-17):
>> On Sun, 17 Dec 2017 at 13:32:55 +0100, Cyril Brulebois wrote:
>>> Jonas Meurer <jonas at freesources.org> (2017-12-17):
>>>> Debian-boot is Cc'ed as cryptsetup provides udebs, so
>>>> debian-installer is affected as well.
>>> 
>>> Thanks for letting us (debian-boot@) know. AFAICT, on the udeb side
>>> we only have crypsetup-udeb that depends on its library udeb, and no
>>> other udebs are in the loop.
>> 
>> FWIW 2:2.0.0~rc1-1 (and soon 2:2.0.0-1) adds new dependencies on
>> libargon2-0 and libjson-c3, that don't have udebs yet.  We filed
>> #880525 and #880526 on Nov. 1 but didn't hear back from the respective
>> maintainers yet, and so far didn't have time to write the patches
>> ourselves.
> 
> FWIW, feel free to (x-debbugs-)cc debian-boot@ when requesting such
> additions; you might get some feedback like a patch or two, or
> alternative routes to consider.
> 
> I hadn't spotted libcryptsetup12-udeb isn't installable due to these
> dependencies, as experimental isn't checked automatically:
> https://d-i.debian.org/dose/

Makes sense, sorry for not doing so.
 
> I've added this as a todo item, along with looking into src:argon2 and
> src:json-c. I'll try to look into that next week (ping welcome), but
> we'll need to get those packages past NEW; it would be appreciated to
> only start the cryptsetup transition once dependencies can be satisfied,
> to avoid breaking d-i daily builds purposefully.

Ack.  I see mejo has just requested the transition slot in #884618, that
means we should we block that bug by #88052[56], right?

> Also, from one the those two bugs: “cryptsetup ≥2.0.0 introduces a new
> on-disk “LUKS2” format, which support Argon2i and Argon2id as PBKDF.”
> 
> Is that a new default format? Does it need any special handling from
> d-i components, like options or files to create, or is that just a
> transparent change for cryptsetup callers?

The format isn't the new default in the sense that `cryptsetup
luksFormat` still creates “legacy” LUKS (version 1) devices, and one
needs to append `--type luks2` to create LUKS2 devices.  Opening a LUKS2
block device does require a locking directory[0] (/run/lock/cryptsetup),
but partman-crypto can stay as is as long as it keeps creating LUKS1
devices.

Not sure what's upstream's intention regarding making `cryptsetup
luksFormat` create LUKS2 devices by default, but at this stage it seems
precipitated to switch to LUKS2 in d-i: I'd rather stick to upstream's
default, especially considering the following snippets of their v2.0.0
Release Notes:

    “Please note that […] the LUKS2 on-disk format itself are new
    features and can contain some bugs.”
    — https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/v2.0.0-ReleaseNotes#L15

(And FWIW it's possible to later in-place convert a device from LUKS1 to
LUKS2 format using `cryptsetup convert`, although it of course won't
magically upgrade the crypto & PKDF algorithms.)

> Alternatively, instead of waiting for udebs to be available for the
> dependencies, maybe support for those two libraries could be patched
> out temporarily in the cryptsetup udebs?

For libargon2-0 it should be a matter of changing the default PBKDF back
to pbkdf2, but I don't see a way to drop the libjson-c3 dependency
unless we compile cryptsetup without LUKS2 support (LUKS2 headers
contain metadata stored in JSON format [1]), which is not trivial
AFAICT.

Cheers,
-- 
Guilhem.

[0] https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/man/cryptsetup.8#L1346
[1] https://gitlab.com/cryptsetup/cryptsetup/blob/v2.0.0/docs/LUKS2-format.txt#L33
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20171218/6448a50e/attachment.sig>