[Pkg-utopia-maintainers] Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20190721/bb1c8deb/attachment.sig>