RL 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:
# + plain mode: Set default cipher to aes-xts-plain64 and password hashing
# to sha256. This is a backward incompatible change for plain mode when
# relying on the defaults. It doesn't affect LUKS volumes. Defaults for
# plain mode should not be relied upon anyway; for many releases the
# Debian wrappers found in the 'cryptsetup' binary package spew a loud
# warning when 'ciphers' or 'hash=' are not explicitly specified in the
# crypttab(5) options of plain devices. The cryptsetup(8) executable now
# issue such a warning as well.
(But I can't answer any of your questions, except that I noticed a
mention elsewhere of plain mode being the default.)
>> 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", 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).
(I see crypttab(5) is absolutely infested with resps.)
> 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.
>> 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...")
> (assuming LUKS is a noun) "by LUKS" not "for LUKS"?
(No idea.)
> 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?
(No idea.)
>> 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.
>> 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.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
