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 theaforementioned via s-p-u in case we have more reports ;-)
Sounds like a good plan. Thanks for taking care, Guilhem :) Cheers jonas
OpenPGP_signature
Description: OpenPGP digital signature