FS#66498 - [cryptsetup] 2.3.2-1: Show warning about changed "allow-discards" behaviour on package upgrade

Attached to Project: Arch Linux
Opened by Pascal Ernster (hardfalcon) - Friday, 01 May 2020, 19:06 GMT
Last edited by freswa (frederik) - Sunday, 13 September 2020, 15:20 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Christian Hesse (eworm)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Cryptsetup 2.3.2-1 refuses to open a LUKS2 device with hmac(sha512) for integrity and the "allow-discards" flag set in the LUKS2 header with the error message "Discard/TRIM is not supported.", which breaks the boot process if that flag is set (which older versions allowed users to do). Cryptsetup 2.3.1-3 opens the very same devices without any complaint whatsoever - not even a warning is shown.

This is obviously an especially grave issue for people using full disk encryption on remote systems with cryptsetup unlock over SSH on reboot. Also, at least when using the "sd-encrypt" mkinitcpio hook, users won't even see cryptsetup's error message, making debugging the issue needlessly cumbersome.

The new behaviour is loosely documented in upstream's changelog [1], but since this can break the boot process for people, there should be a warning message displayed when the cryptsetup package is upgraded to the new version.

[1] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.3/v2.3.2-ReleaseNotes
This task depends upon

Closed by  freswa (frederik)
Sunday, 13 September 2020, 15:20 GMT
Reason for closing:  Upstream
Additional comments about closing:  https://gitlab.com/cryptsetup/cryptsetup /-/issues/558
Comment by Pascal Ernster (hardfalcon) - Friday, 01 May 2020, 21:59 GMT
I've filed a bug about this with upstream, but IMHO there should still be a warning shown when upgrading to cryptsetup 2.3.2 until there's a fix from upstream.

https://gitlab.com/cryptsetup/cryptsetup/-/issues/558
Comment by loqs (loqs) - Friday, 01 May 2020, 22:15 GMT
What if you revert https://gitlab.com/cryptsetup/cryptsetup/-/commit/790666ffb08681c259db8d4b01d5d284cd493e9d
Comment by Pascal Ernster (hardfalcon) - Saturday, 02 May 2020, 10:31 GMT
loqs: Upstream have showed me a way to remove the flag again:
https://gitlab.com/cryptsetup/cryptsetup/-/issues/558#note_335279806

"cryptsetup refresh $luksname --persistent" works only with opened/unlocked LUKS devices though, so it required a temporary downgrade to cryptsetup 2.3.1.

Loading...