cryptsetup header in-place decryption - reporting about a bug alert

Hi all,

In this email I'm reporting about an issue that I read about:

Regarding the webpage "Removing system encryption" in website
"archlinux.org" - link:

https://wiki.archlinux.org/title/Removing_system_encryption#Decrypting_LUKS2_devices_in-place

There is the following text under the subtitle "Decrypting LUKS2
devices in-place":

> Warning: As of 2020, and version 2.3.3, when using cryptsetup to
> decrypt a LUKS2 block device the program requires you to provide a
> LUKS --header file. If you do not use the "detached header" feature
> of LUKS, and naively try to pass the block device itself (which
> contains a LUKS2 header) as the subject of the --header, cryptsetup
> will accept this and go ahead with alleged decryption. Afterwards the
> block device will show up as a LUKS2 device with no key-slots, and
> your data will be lost. If you try to use cryptsetup luksHeaderBackup
> as the header file used with --header, your data will be lost. If you
> try to restore a backed-up header after this faulty decryption, your
> data will still be lost.
>
> If you still went ahead with the decryption, the data might be
> recoverable by shifting the partition start after the now defunct
> LUKS header: [1], still, do not rely on this.

Note: I did NOT test this, though I'd rather let you know about it.

Thank you.
David.