Started GNOME Disks, trying to change my disk encryption password: https://tracker.pureos.net/w/pureos/tips/change_disk_encryption_password/
Error is reported:
After restart I was not able to unlock my disk! Neither old or the new password worked.
Perhaps a candidate for reporting upstream.
@jeremiah.foster as per @chris.lamb advice, I want to raise a concern about this, we either need to fix it now, or to somehow warn users about this issue.
It looks like using GNOME disks may change the LUKS header file when it does a wipefs. I would warn users about this and instead refer folks to this resource: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#2-setup
Here are the warnings from cryptsetup's FAQ. We need to determine which one is relevant to GNOME Disks before advising users to use GNOME disks.
DISTRIBUTION INSTALLERS: Some distribution installers offer to create LUKS containers in a way that can be mistaken as activation of an existing container. Creating a new LUKS container on top of an existing one leads to permanent, complete and irreversible data loss. It is strongly recommended to only use distribution installers after a complete backup of all LUKS containers has been made.
UBUNTU INSTALLER: In particular the Ubuntu installer seems to be quite willing to kill LUKS containers in several different ways. Those responsible at Ubuntu seem not to care very much (it is very easy to recognize a LUKS container), so treat the process of installing Ubuntu as a severe hazard to any LUKS container you may have.
NO WARNING ON NON-INTERACTIVE FORMAT: If you feed cryptsetup from STDIN (e.g. via GnuPG) on LUKS format, it does not give you the warning that you are about to format (and e.g. will lose any pre-existing LUKS container on the target), as it assumes it is used from a script. In this scenario, the responsibility for warning the user and possibly checking for an existing LUKS header is shifted to the script. This is a more general form of the previous item.
LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not used in deriving the master key. It is used in decrypting a master key that is randomly selected on header creation. This means that if you create a new LUKS header on top of an old one with exactly the same parameters and exactly the same passphrase as the old one, it will still have a different master key and your data will be permanently lost.
PASSPHRASE CHARACTER SET: Some people have had difficulties with this when upgrading distributions. It is highly advisable to only use the 95 printable characters from the first 128 characters of the ASCII table, as they will always have the same binary representation. Other characters may have different encoding depending on system configuration and your passphrase will not work with a different encoding. A table of the standardized first 128 ASCII characters can, e.g. be found on http://en.wikipedia.org/wiki/ASCII
KEYBOARD NUM-PAD: Apparently some pre-boot authentication environments (these are done by the distro, not by cryptsetup, so complain there) treat digits entered on the num-pad and ones entered regularly different. This may be because the BIOS USB keyboard driver is used and that one may have bugs on some computers. If you cannot open your device in pre-boot, try entering the digits over the regular digit keys.
This affects Ubuntu as well, leading me to believe the issue is upstream in GNOME disks; https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/1790979
What evidence is there that the password was "destroyed"? Is it possible that something else happened? I say this because the GNOME disks dialog is stating that there was an error changing the passphrase, it doesn't say that the password was changed or destroyed.
@jeremiah.foster Perhaps this might help:
Before password change:
After password change via GNOME Disks:
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928893 indicates that this has been fixed.
I tested this in a Byzantium image in Boxes. It worked, I was able o change the disk encryption passphrase twice on the same VM.
@jeremiah.foster do we have a tag Like: fixed in Byzantium that we can put on this ticket so we close it when we move to Byzantium?