Hi, On Sun, 21 Jul 2019 at 13:36:06 +0200, Michael Biebl wrote: > Agreed. I've just uploaded a libblockdev with that cherry-pick to buster > and this change was acked by the SRMs, so should be in 10.1.
Awesome! :-) > Regarding the LUKS2/udisks2/LimitMEMLOCK issue, would you prefer to > track this as a udisks2 issue or cryptsetup issue? Is there already a > bug report for this or should we clone/reassign this one? I filed https://gitlab.com/cryptsetup/cryptsetup/issues/465 “Argon2i/d benchmark doesn't honor `getrlimit(RLIMIT_MEMLOCK,)`”, but on second thought I don' think udisks2 is affected. As I wrote in Message #59, | Apologies for incorrectly pointing to getrlimits(2) earlier: I'm | personally not familiar with udisks/libblockdev myself and hadn't | realized `getrlimit(RLIMIT_MEMLOCK,)` was bypassed since the Argon2d/i | benchmark process is privileged. Now that libblockdev uses crypt_keyslot_change_by_passphrase() there is AFAICT nothing more to be done on the libblockdev or udisks2 side with respect to that bug. But maybe the Changelog entry for libblockdev 2.20-7+deb10u1 should be changed to remove the references to MEMLOCK. As I wrote in https://gitlab.com/cryptsetup/cryptsetup/issues/466 I believe the problem with LUKSv2 is elsewhere (crypt_get_volume_key_size() fails because there is no bound keyslot object to retrieve the key size from). Maybe changing it to * Use existing cryptsetup API for changing keyslot passphrase. Cherry-pick upstream fix to use existing cryptsetup API for atomically changing a keyslot passphrase, instead of deleting the old keyslot before adding the new one. This avoids data loss when attempting to change the passphrase of a LUKS2 device via udisks2, e.g. from GNOME Disks. Deleting a keyslot and then adding one is risky: if anything goes wrong before the new keyslot is successfully added, no usable keyslot is left and the device cannot be unlocked anymore. There's little chances this causes actual problems with LUKS1, but as of 2.1.0 libcrypsetup fails to add a new keyslot to a LUKS2 header without any pre-existing keyslot. (Closes: #928893) Or maybe remoing the last sentence alltogether, ending with “[…] cannot be unlocked anymore.” Cheers, -- Guilhem.
signature.asc
Description: PGP signature
