Sorry, didn't receive the follow-up on the bug (and forgot I had filed the request in the first place). And https://lists.debian.org/debian-doc/2024/05/msg00003.html never made it to the bug it seems.
On Sun, 5 May 2024 at 17:29:03 +0100, Justin B Rye wrote: > L wrote (https://lists.debian.org/debian-doc/2024/05/msg00003.html): >> Guilhem Moulin <guil...@debian.org> writes: >>> cryptsetup 2:2.7.0~rc0-1 has a backward incompatible change for plain >>> mode when relying on defaults cipher and password hashing algorithm. >>> >>> The change affects users upgrading from bookworm to trixie. Plain mode >>> is generally advised against but it still makes sense to include the >>> NEWS entry into the release notes. >> >> The text needs a bit of intro/context to be readable by an end-user. Can >> you give some pointers to explain the basic issue here - what is "plain >> mode"? is it the default now? what is the change, and what is the user >> meant to do about in response to this change? what is the >> "incompatability"? > > I imagine it's connected with the Changelog entry saying: > […] > (But I can't answer any of your questions, except that I noticed a > mention elsewhere of plain mode being the default.) plain mode is the default when the crypttab(5) option field doesn't specify any other type (luks, tcrypt, etc.). However I suspect most users don't edit crypttab(5) manually, but instead do it automatically at installation time (via d-i) which always sets the type explicitly. d-i's default “LVM-over-crypt” setup sets up LUKS devices, but users can choose (explicit) plain in the menu too if they choose to do so. Technically, “plain mode” means the device is mapped directly using a key derived from a passphrase. Unlocking a device in plain mode is always successful (there is no error checking), and unlocking with different parameters (cipher, digest algorithm, key size, etc.) yields different mapped devices. Unlike LUKS, there is no header to check whether the passphrase is correct, nor to store algorithms: consumers need to always pass algorithms consistently at mapping time for non-transient devices. (Generally, cryptsetup has consistently advised not to use plain mode for non-transient devices.) Those who rely on default algorithms for non-transient devices will experience a regression when upgrading from bookworm to trixie. To fix the regression, they will need to explicitly pass the previous defaults using `--cipher aes-cbc-essiv:sha256 --hash ripemd160` (CLI), or `cipher=aes-cbc-essiv:sha256,hash=ripemd160` (crypttab). I expect the latter to be far fewer though, since we're already spewing a warning that default are not be relied upon for plain mode; but only when processing crypttab(5), the cryptsetup(8) binary didn't spew such a warning before 2:2.7.0. >>> Default cipher and password hashing for plain mode have respectively >>> been changed to aes-xts-plain64 and sha256 (from aes-cbc-essiv:sha256 >>> resp. ripemd160). >> >> It would help to start with "The" before "default". >> >> what does "resp." mean in this context? > > This one I know (and there's a clue earlier in the sentence): it's a > common non-native-English-speakerism. "Resp." is short for "and/or > respectively", Yup, and I was not aware that wasn't proper English, thanks. > but it's used where anglophones would be more likely to > use plain "and" or "or", and it's a warning sign of a tortuously > organised sentence. I'd suggest: > > The default cipher has been changed to aes-xts-plain64 (from > aes-cbc-essiv:sha256), and the default hash to sha256 (from ripemd160). Make sense. >> Is there a crucial word missing after "hashing" - should it be "hash >> function"? > > That (or "password hashing algorithm") would be more natural English, > but it might be better to stick to "hash" since that's the name of the > crypttab field. I think I meant to write hash algorithm here, but hash probably works too. >>> The new values matches what is used for LUKS, but the change does NOT >>> affect LUKS volumes. >> >> "value" not "values" here > > (In fact I think he means "the new values match what is used...") Correct. >> (assuming LUKS is a noun) "by LUKS" not "for LUKS"? LUKS is an acronym and stands for Linux Unified Key Setup. >> the bit after the comma is pretty confusing to a non-expert like me, >> what are you trying to say here? would i expect a change in cryptsetup >> what *does* the change affect? I don't understand the second sentence, but hopefully my first paragraph clarifies what I tried to say. 1/ Upstream's choice of new default algorithms for plain devices matches what has already been used as default for LUKS. In retrospect that might only be a curiosity though, so not worth mentioning in the release notes. 2/ The new default don't affect LUKS devices, since those have a header area where cipher, hash algorithm, etc. are stored as metadata so don't need to be passed explicitly at mapping time. >>> This is a backward incompatible change for plain mode when relying on >>> the defaults, which (for plain mode only) is strongly advised >>> against. >> >> i'm afraid I cant make any sense out of this paragraph! what is >> "strongly advised against"? > "Relying on the defaults" - that is, leaving the fields empty in > crypttab. Yup, or using the cryptsetup(8) binary without --hash or --cipher options. >>> For many releases the Debian wrappers found in the ‘cryptsetup’ binary >>> package have spewed a loud warning for plain devices from crypttab(5) >>> where ‘cipher=’ or ‘hash=’ are not explicitly specified. The >>> cryptsetup(8) executable now issue such a warning as well. >> >> Is this an unrelated change or is there some link to the above? > > Part of the same deprecation process. Correct. Thanks for the reading and suggested improvements! -- Guilhem.
signature.asc
Description: PGP signature
