Hey Guilhem :)

Guilhem Moulin wrote:
I'm not sure how what the best way to proceed for Bullseye.  Jonas,
what's your take about this?

First sorry for not responding earlier. I simply missed this mail in my backlog :-/

I tried to summarize the regression at
https://gitlab.com/cryptsetup/cryptsetup/-/issues/648#note_575895772 .
(Note that the truncation doesn't affect LUKS or dm-crypt, but *only*
standalone dm-integrity devices using HMAC integrity protection with
long key files, which is not widespread.)  It manifests in different
ways depending on cryptsetup and kernel versions:

   * Stretch has cryptsetup <2.0.0 which doesn't have integritysetup(1)
     and is therefore unaffected.
   * For cryptsetup ≥2.0.0 and ≤2.0.4 (some time between the Stretch and
     Buster releases), devices are formatted and opened using a
     *106-bytes* truncation of the key material.  Moreover formatting
     errors out when default sector size 512 bytes is used (so one needs
     to format with --sector-size [1024|2048|4096]).
   * For cryptsetup ≥2.0.5 (Buster and Bullseye), devices are formatted
     and opened using a *114-bytes* truncation of the key material.

So dm-integrity devices that were formatted using cryptsetup ≥2.0.0 and
≤2.0.4 using HMAC integrity protection with >106-bytes long keys don't
open normally (one needs to use `--integrity-key-size 106`) in Buster
and later.  We uploaded 2:2.0.5-1 to sid on October 29 2018; an entire
recycle cycle has since gone by and so far only n.f.b. has reported the
issue.  Given the many “if”s and the lack of bug reports I think it's
fair to assume than not maybe used long HMAC keys with integritysetup
between v2.0.0 and v2.0.4.

In addition: when using cryptsetup ≥2.3 on Linux 5.5 or later, it's not
possible to open a dm-integrity device using HMAC integrity protection
with keys of size exceeding *113 bytes*, regardless of whether it was
formatted using the same integritysetup binary or an older version.
cryptsetup 2:2.3.0-1 and linux 5.5.13-1 were respectively uploaded to
sid on March 04 and March 30 2020; Bullseye is affected and one year
later no one has reported the issue.

I would suggest to take the most pragmatic approach and don't care about this corner case. Given that, no stable release ever shipped with a faulty integritysetup and that I would expect every user who ran unstable/testing back when keys hat 106 bytes to still run unstable/testing, let's just keep it the way it is, no?

So I think we should postpone 2:2.3.6-1 to Bookworm.

Agreed.

Maybe we
should just wait until Bullseye is released, and upload the
aforementioned via s-p-u in case we have more reports ;-)

Sounds like a good plan.

Thanks for taking care, Guilhem :)

Cheers
 jonas


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to