Debian Bug report logs - #928893
gnome-disk-utility: disk content permanently lost when changing LUKS password

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Svjatoslav Agejenko <svjatoslav@svjatoslav.eu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sun, 12 May 2019 20:56:02 +0300

Package: gnome-disk-utility
Version: 3.30.2-3
Severity: important

Dear Maintainer,

   * What led up to the situation?

Install system using normal full disk encryption LUKS+Ext4.
After install open gnome-disk-utility and change
encryption password. It gives some error dialog and
now you are royally screwed. It deleted the only
LUKS keyslot. Cannot add new keyslots because of that.
All data will be lost after reboot.

Here is output of luksdump:

udo cryptsetup luksDump /dev/sda5
LUKS header information
Version:        2
Epoch:          4
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           3c16ad4c-294c-4547-bf3e-bb8864ba5ea3
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

Data segments:
  0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]

Keyslots:
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 59904
        Salt:       XX XX XX XX XX ....
        Digest:     XX XX XX XX XX ...

----------------------------------------

I changed salt and digest. No Keyslots are present!!!

I tried this 2 times in a row with new install,
exactly same result.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.0.8-xanmod5 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-disk-utility depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  libatk1.0-0                                  2.30.0-2
ii  libc6                                        2.28-10
ii  libcairo2                                    1.16.0-4
ii  libcanberra-gtk3-0                           0.30-7
ii  libdvdread4                                  6.0.1-1
ii  libgdk-pixbuf2.0-0                           2.38.1+dfsg-1
ii  libglib2.0-0                                 2.58.3-1
ii  libgtk-3-0                                   3.24.5-1
ii  liblzma5                                     5.2.4-1
ii  libnotify4                                   0.7.7-4
ii  libpango-1.0-0                               1.42.4-6
ii  libpangocairo-1.0-0                          1.42.4-6
ii  libpwquality1                                1.4.0-3
ii  libsecret-1-0                                0.18.7-1
ii  libsystemd0                                  241-3
ii  libudisks2-0                                 2.8.1-4
ii  udisks2                                      2.8.1-4

gnome-disk-utility recommends no packages.

gnome-disk-utility suggests no packages.

-- no debconf information

Message #12 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Marco Villegas <marco@marvil07.net>

To: 928893@bugs.debian.org

Subject: Confirming gnome-disks problem

Date: Wed, 3 Jul 2019 12:43:28 -0500

[Message part 1 (text/plain, inline)]

Starting from buster installer rc3, and installing minimal dependencies
to run, I can confirm the problem exists.

While trying to change the passphrase from gnome-disks, i.e. the old
and new passphrases were entered, I see the following error message:
"Error changing passphrase: Invalid argument (udisks-error-quark, 0)",
screenshot attached.

I have also tried to access again the disk from an external gparted
after the attempt, and I could not unlock the partition with neither
the old nor the new passphrase.

Best,

[gnome-disks-error-buster-rc3.png (image/png, attachment)]

Message #19 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: 928893@bugs.debian.org, debian-doc@lists.debian.org

Subject: Re: Confirming gnome-disks problem

Date: Wed, 3 Jul 2019 21:00:22 +0200

[Message part 1 (text/plain, inline)]

Control: clone -1 -2
Control: reassign -2 release-notes

On Wed, 3 Jul 2019 12:43:28 -0500 Marco Villegas <marco@marvil07.net> wrote:
> Starting from buster installer rc3, and installing minimal dependencies
> to run, I can confirm the problem exists.
> 
> While trying to change the passphrase from gnome-disks, i.e. the old
> and new passphrases were entered, I see the following error message:
> "Error changing passphrase: Invalid argument (udisks-error-quark, 0)",
> screenshot attached.
> 
> I have also tried to access again the disk from an external gparted
> after the attempt, and I could not unlock the partition with neither
> the old nor the new passphrase.

Let's document this in the release notes to warn people as this won't
get fixed in buster before the release.

Paul

[signature.asc (application/pgp-signature, attachment)]

Message #26 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Narcis Garcia <debianlists@actiu.net>

To: 928893@bugs.debian.org

Subject: Workaround

Date: Sat, 6 Jul 2019 06:36:57 +0200

Simple:
A) Package gnome-disk-utility with this feature disabled, until bug is
solved.
B) Not including buggy gnome-disk-utility in repositories

Is really dangerous for people to have this possibility to loss their
data, because of a small piece of bad code or bad release decision.

-- 


__________
I'm using this express-made address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.

Message #31 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Narcis Garcia <debianbugs@actiu.net>

To: 928893@bugs.debian.org

Cc: 927165@bugs.debian.org

Subject: More details

Date: Fri, 12 Jul 2019 16:53:23 +0200

I don't find today any filed bug about this in gnome-disks tracker:
https://gitlab.gnome.org/GNOME/gnome-disk-utility/issues
and I'm not finding the way to register a user account to file a new bug
report there.

I've made some testing and bug seems only reproducible with LUKS2
formatted volumes. LUKS1 ones work perfectly, and gnome-disks by default
uses LUKS1 when creating new encrypted volumes.

I believe main problematic scenarios are:

1. When using gnome-disks to change passphrase for volumes created
during OS installation (Buster's DebianInstaller formats in LUKS2, and
no one of Cyril's proposals have been implemented, as expert install
question or kernel line option)

2. When using gnome-disks to change passphrase for volumes created with
other software, and user doesn't care about LUKS version.

Easiest solutions seem to be now:

A) Switching back DebianInstaller to use LUKS1 by default.

B) Not including buggy gnome-disk-utility in repositories, until Gnome's
bug is solved.

Message #38 received at 928893@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: 928893@bugs.debian.org

Cc: Guilhem Moulin <guilhem@debian.org>

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Fri, 19 Jul 2019 22:14:49 -0300

[Message part 1 (text/plain, inline)]

Control: reassign -1 libblockdev-crypto2
Control: found -1 2.20-7
Control: fixed -1 2.22-1
Control: affects -1 gnome-disk-utility
Control: affects -1 udisks2
Control: tag -1 + patch

Hi,

it turns out this is caused by a bug in libblockdev, which is fixed in
sid already (although it seems like upstream applied the fix for
unrelated reasons and it's not clear whether they realized this bug
was a possibility).

The attached patch fixes it for me:

 - current sid (libblockdev 2.22-1): unreproducible
 - current sid with Buster's libblockdev 2.20-7: reproduced the bug
 - current sid with Buster's libblockdev + the attached patch: unreproducible

I think we should get this into Buster (10.1, if not via stable-updates).

As explained in the changelog entry, this fixes the data loss problem
but it might still leave udisks2's LUKS2 passphrase changing broken in
some cases, although broken in a way that leaves the old passphrase
working, which is better than making the device totally unusable.
Guilhem (Cc'ed) and I are investigating this possible problems and
potential solutions.

Cheers,
-- 
intrigeri

[928893.patch (text/x-diff, attachment)]

Message #59 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: intrigeri <intrigeri@debian.org>, 928893@bugs.debian.org

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sat, 20 Jul 2019 06:01:35 -0300

[Message part 1 (text/plain, inline)]

Hi there,

On Fri, 19 Jul 2019 at 22:14:49 -0300, intrigeri wrote:
> it turns out this is caused by a bug in libblockdev, which is fixed in
> sid already (although it seems like upstream applied the fix for
> unrelated reasons and it's not clear whether they realized this bug
> was a possibility).

AFAICT there were two bugs in src/plugins/crypto.c:bd_crypto_luks_change_key_blob()

    https://sources.debian.org/src/libblockdev/2.20-7/src/plugins/crypto.c/#L1359

The API calls to libcryptsetup roughly goes as follows:

    keyslot = crypt_volume_key_get(cd, …, volume_key, old_passphrase);
    crypt_keyslot_destroy(cd, keyslot);
    crypt_keyslot_add_by_volume_key(cd, 0, volume_key, new_passphrase);

The first call uses the old passphrase to unlock a keyslot and set the
volume key.   (In LUKS2 the volume key of open devices isn't accessible
to userspace, but of course it's no problem here since the passphrase is
used to unlock a keyslot, which yields the volume key.)

The second call removes the keyslot used to get the volume key in the
first call.

The third call adds a new key slot with the new passphrase.


There are IMHO two issues with these calls (regardless of the LUKS
format version):

  1. It only adds the new slot *after* deleting the old one, so there is
     moment where the LUKS header might have no active key slot left.
     Worse, if crypt_keyslot_add_by_volume_key() fails for whichever
     reason, then the header is left in a broken state; if the user
     doesn't notice and closes the mapped device (or simply reboots)
     then the entire content of the device is lost.

  2. The second argument of crypt_keyslot_add_by_volume_key() is always 0,
     while the user might want to change another key slot.

I'm unfortunately not familiar with libblockdev, but the attached
program, to be linked against libcryptsetup, shows these problems
AFAICT.


Format a device as LUKSv1 (although the same happens with v2), with a
random passphrase for key slot 0, and passphrase “test” for key slot
1.  (The extra PBKDF argument are there just so the test doesn't take
too long.)
    
    $ dd if=/dev/zero of=/tmp/disk.img bs=1M count=64
    $ head -c 32 /dev/urandom >/tmp/keyslot0
    $ cryptsetup luksFormat --pbkdf-force-iterations 1000 --type luks1 \
        -q --key-file=/tmp/keyslot0 /tmp/disk.img
    $ cryptsetup luksAddKey --pbkdf-force-iterations 1000 \
        --key-file=/tmp/keyslot0 -q /tmp/disk.img <<<test
    $ ./928893 /tmp/disk.img "test" "test2"
    Key slot 0 is full, please select another one.
    928893: Error: crypt_keyslot_add_by_volume_key

The third API call fails because key slot 0 is already enabled.  But key
slot 1 was already removed.


Re-format the device as LUKSv2, with a single key slot unlocked with
passphrase “test”.

    $ cryptsetup luksFormat --pbkdf-force-iterations 4 --pbkdf-memory 32 \
        --type luks2 -q /tmp/disk.img <<<test
    $ ./928893 /tmp/disk.img "test" "test2"
    Failed to initialise default LUKS2 keyslot parameters.
    928893: Error: crypt_keyslot_add_by_volume_key

Ka-boom, the only key slot was removed but not re-created.  The whole
device will be lost when the user reboot.  This *may* also happen with v1
if for whatever reason (hardware failure for instance) the new key slot
can't be added.  But it *always* happens with LUKSv2, which is Buster's
default LUKS format version for `luksFormat`.

Investigating further why crypt_keyslot_add_by_volume_key() *always*
fails with LUKSv2, with some help from gdb I believe the calltrace goes
as follows:

    lib/setup.c:crypt_keyslot_add_by_volume_key()
        calls crypt_keyslot_add_by_key() at line 3414
    lib/setup.c:crypt_keyslot_add_by_key()
        calls LUKS2_keyslot_params_default() at line 5291
    lib/luks2/luks2_keyslot.c:LUKS2_keyslot_params_default()
        calls crypt_keyslot_get_encryption() at line 154
    lib/setup.c:crypt_keyslot_get_encryption()
        calls crypt_get_volume_key_size() at line 4634
    lib/setup.c:crypt_get_volume_key_size()
        calls LUKS2_get_volume_key_size() at line 4550, which returns -1
        and cd->volume_key is NULL so crypt_get_volume_key_size()
        returns 0

LUKS2_get_volume_key_size() fails because the key size is specified in
the ‘keyslots’ object of LUKSv2's JSON header [0], and that object is
the empty array at that point.  The volume key is known to the caller,
but not to crypt_keyslot_get_encryption().  This is arguably a libcryptsetup
bug, but blindly calling crypt_keyslot_add_by_volume_key() *after*
crypt_keyslot_destroy() is extremely problematic in itself, and
usingcrypt_keyslot_add_by_volume_key() on an header without any
key-slots is of limited interest.  As intrigeri wrote, libblockdev 2.22
fixes the problem by replacing these 2 libcryptsetup API calls with the
more robust crypt_keyslot_change_by_passphrase() (available in
libcryptsetup ≥1.6.0).

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.

Cheers,
-- 
Guilhem.

[0] https://gitlab.com/cryptsetup/LUKS2-docs/blob/master/luks2_doc_wip.pdf
    sec. 3.2

[928893.c (text/x-csrc, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #64 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: 928893@bugs.debian.org

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sat, 20 Jul 2019 17:24:21 -0300

[Message part 1 (text/plain, inline)]

On Sat, 20 Jul 2019 at 06:01:35 -0300, Guilhem Moulin wrote:
> LUKS2_get_volume_key_size() fails because the key size is specified in
> the ‘keyslots’ object of LUKSv2's JSON header [0], and that object is
> the empty array at that point.

Forgot to add another data point which supports my claim: with a LUKSv2
device with two active key slots (#0 unlocked by passphrase “test” and
#1 unlocked by a random passphrase), LUKS2_get_volume_key_size()
succeeds and so does crypt_keyslot_add_by_volume_key().

    $ cryptsetup luksFormat --pbkdf-force-iterations 4 --pbkdf-memory 32 \
        --type luks2 -q /tmp/disk.img <<<test
    $ cryptsetup luksAddKey --pbkdf-force-iterations 4 --pbkdf-memory 32 \
        --new-keyfile-size 32 /tmp/disk.img /dev/urandom <<<test
    $ ./928893 /tmp/disk.img "test" "test2"

Works fine.  The first (index #0) key slot is updated with the new
passphrase, while the other (random) one is left unchanged.  It works
because by the time crypt_keyslot_add_by_volume_key() is called there is
a bound (ie assigned to a segment) keyslot left, and the volume key size
can be obtained from its ‘key_size’ JSON field.

Just filed a bug against cryptsetup / libcryptsetup:
https://gitlab.com/cryptsetup/cryptsetup/issues/466

However as far as libblockdev is concerned, FWIW I fully support
intrigeri's cherry-pick of upstream's 34ed7be.  Adding a key slot
*after* having removed it can have very nasty consequences (entire
device lost), and that not just for LUKSv2.

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #69 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 928893@bugs.debian.org, Guilhem Moulin <guilhem@debian.org>, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sun, 21 Jul 2019 13:36:06 +0200

[Message part 1 (text/plain, inline)]

Hi Guilhem, hi intrigeri,

first of all, thanks for debugging this issue and this excellent bug report!

On Sat, 20 Jul 2019 17:24:21 -0300 Guilhem Moulin <guilhem@debian.org>
wrote:

> However as far as libblockdev is concerned, FWIW I fully support
> intrigeri's cherry-pick of upstream's 34ed7be.  Adding a key slot
> *after* having removed it can have very nasty consequences (entire
> device lost), and that not just for LUKSv2.

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.

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?

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #74 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 928893@bugs.debian.org, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sun, 21 Jul 2019 16:58:36 -0300

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #79 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: Guilhem Moulin <guilhem@debian.org>, 928893@bugs.debian.org, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sun, 21 Jul 2019 22:40:38 +0200

[Message part 1 (text/plain, inline)]

Hi

Am 21.07.19 um 21:58 schrieb Guilhem Moulin:

> 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.”

I already uploaded 2.20-7+deb10u1 with this changelog, so it's not
really possible anymore to undo this other then making a 2.20-7+deb10u2
upload, which seems like overkill to me.
I don't think the changelog is that misleading that we need another
upload fixing it.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Message #84 received at 928893@bugs.debian.org (full text, mbox, reply):

From: Guilhem Moulin <guilhem@debian.org>

To: Michael Biebl <biebl@debian.org>

Cc: 928893@bugs.debian.org, intrigeri <intrigeri@debian.org>

Subject: Re: Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

Date: Sun, 21 Jul 2019 17:46:44 -0300

[Message part 1 (text/plain, inline)]

On Sun, 21 Jul 2019 at 22:40:38 +0200, Michael Biebl wrote:
> I already uploaded 2.20-7+deb10u1 with this changelog, so it's not
> really possible anymore to undo this other then making a 2.20-7+deb10u2
> upload, which seems like overkill to me.
> I don't think the changelog is that misleading that we need another
> upload fixing it.

Ack, agreed

-- 
Guilhem.

[signature.asc (application/pgp-signature, inline)]

Message #89 received at 928893-close@bugs.debian.org (full text, mbox, reply):

From: Michael Biebl <biebl@debian.org>

To: 928893-close@bugs.debian.org

Subject: Bug#928893: fixed in libblockdev 2.20-7+deb10u1

Date: Mon, 22 Jul 2019 00:17:08 +0000

Source: libblockdev
Source-Version: 2.20-7+deb10u1

We believe that the bug you reported is fixed in the latest version of
libblockdev, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 928893@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Biebl <biebl@debian.org> (supplier of updated libblockdev package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Sat, 20 Jul 2019 23:18:18 +0200
Source: libblockdev
Architecture: source
Version: 2.20-7+deb10u1
Distribution: buster
Urgency: medium
Maintainer: Utopia Maintenance Team <pkg-utopia-maintainers@lists.alioth.debian.org>
Changed-By: Michael Biebl <biebl@debian.org>
Closes: 928893
Changes:
 libblockdev (2.20-7+deb10u1) buster; urgency=medium
 .
   [ intrigeri ]
   * 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 LUKS2 defaults to the memory-hard
     Argon2 key derivation algorithm, which is implemented in cryptsetup with
     the assumption that it runs as root with no MEMLOCK ulimit; this
     assumption is wrong when run by udisks2.service under
     LimitMEMLOCK=65536, which breaks adding the new keyslot, and makes us
     hit the problematic situation (user data loss) every time.
     With this change, changing a LUKS2 passphrase via udisks2 will still
     fail in some cases, until the MEMLOCK ulimit problem is solved in
     cryptsetup or workaround'ed in udisks2. But at least, if it fails, it
     will fail _atomically_ and the original passphrase will still work.
     (Closes: #928893)
Checksums-Sha1:
 abcae3dc4fc1657fa12a39243c2e8878294ebb70 5272 libblockdev_2.20-7+deb10u1.dsc
 cc489f865e551e041eb56e5d533ed55981bec59f 12856 libblockdev_2.20-7+deb10u1.debian.tar.xz
 0bbc390da128acef689302307e2734f38bdf5c13 9334 libblockdev_2.20-7+deb10u1_source.buildinfo
Checksums-Sha256:
 84dc2b491db463b76bb4988d6af60ab8d0c3cc2eca18d03f8eb39264d910eb58 5272 libblockdev_2.20-7+deb10u1.dsc
 758afa7d6eff828ed8cce003b78f837a00627133fa454e12696db889066ee7df 12856 libblockdev_2.20-7+deb10u1.debian.tar.xz
 9e7be20c1d325039555225b0734c3efcca578b1e9e6b126feb2b03280d911e06 9334 libblockdev_2.20-7+deb10u1_source.buildinfo
Files:
 942d745f73bd614a684c5040dab2bd8a 5272 libs optional libblockdev_2.20-7+deb10u1.dsc
 94c00a865753f97ad80627168259efa1 12856 libs optional libblockdev_2.20-7+deb10u1.debian.tar.xz
 5c0a7df91ebad04c347e9a28d3210fb0 9334 libs optional libblockdev_2.20-7+deb10u1_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEECbOsLssWnJBDRcxUauHfDWCPItwFAl0zq9gACgkQauHfDWCP
ItySSw/+MZKAomTm/fOLcys04rEKeDzy8+UkyiALF0hCQyHfnk12Ov9HEQpWvnwQ
dQ91VpKF8IdTLGCBXK0S3K2UOBJpA2JGv0qw5/8v+vrN0xAU4eimHNsPWl2ID+uP
5V1dpmOsmJIwx+aCGJEzQ3qnhgtd4sH9uC5zizU42Zox3UuUsBWTpc0Qv/C5N2xv
HVac69FR2FIs5lmUwXaAZ94+hJYzAYb9G/W96+z8NzG/5Xc6N2hM9bAIPyFJ0TXx
fAYiWNWzKIMo4OSK0lwieXTberKDfRVA517MFGJ347fmORie/Qoic14hucQ/yJpU
VRnjTd5F+LgPBgHjq7BctKXcF9ZeZNgz7Q4F9ChhOGe7TclaIG3Br3B1xo9IW/eU
gCmvGEj9rKO3XrBL02xedBFDz2SxCqQRZdPpAt5HFN1xeaB6cHdJcZMAiDz4mFdR
B247lQCmvEYt7gxvOteIH5sFetCfYgtAKwOwr8rs1CNGHDJM0CiGGUjtEnSDtBF1
+900Oi7rPa/btZVelFtaof/7sJW/J92XilNpe4W6EbztcMZ2yMG540A2eewHC8iq
cNIOPho3nnTfBrKTZ2lEiVCNINWUnc3VhS0fNyh1Vr07qBSJO7W3BnZ7tHxDwEYV
UpkiTni184L3bzzvvHz5R1nIpUdTOxsEnrdSMP34QrlhOOqTTJY=
=p9vc
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.