#2504 PR `merged`: Add initial LUKS2 support¶

Labels: enhancement, fixed / solved / done

vcrhonek opened issue at 2020-10-20 12:15:¶

Relax-and-Recover (ReaR) Pull Request Template¶

Please fill in the following items before submitting a new pull request:

Pull Request Details:¶

Type: Bug Fix / New Feature / Enhancement / Other?
Enhancement.
Impact: Low / Normal / High / Critical / Urgent
Normal.
Reference to related issue (URL):
https://github.com/rear/rear/issues/2204
How was this pull request tested?
Quite thoroughly. I've run many backup followed by recover tests on Fedora 32, RHEL 8.2 and Fedora 25 (because there is LUKS1 by default on f25). I didn't notice any issues when I used default encryption during install of the system. I've also tried various ciphers/key-sizes/hash variants to ensure that values given by luksDump parsing on LUKS2 are meaningful and to recreating LUKS1 on system where LUKS2 is default and vice versa.
Brief description of the changes in this pull request:
a) it adds new parameter 'type' to 'crypt' keyword used in disklayout.conf. Using this parameter allows to recreate the same version of LUKS that was on the system
b) it adds LUKS version detection, parsing depending on version and usage of 'type' parameter have been added to
/usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh

I'm aware that this is useful mainly for basic LUKS2 setup (let's say similar to LUKS1), but I believe that even so it could be sufficient for many users.

And I wonder... wouldn't be better to backup and restore complete LUKS header instead of taking values from luksDump and creating new one? That would simplify things a lot and, for example, users won't lose keys from additional keyslots, ...

jsmeix commented at 2020-10-20 12:34:¶

@vcrhonek
wow! Thank you!
We will have a look...

gdha commented at 2020-10-21 08:27:¶

@vcrhonek @jsmeix Do not bother with RHEL/CentOS 6 as it is End-of-Life (EOL) anyhow. In Rear 2.7 we will mark it that way.

jsmeix commented at 2020-10-23 13:09:¶

@gdha
please could you add a new initial release-notes-2-7.md to
https://github.com/rear/rear.github.com/tree/master/documentation
so that I could adapt the "Supported and Unsupported Operating Systems" section
for ReaR 2.7 right now?

jsmeix commented at 2020-10-23 13:10:¶

@vcrhonek
I committed some fixes to your code that hopefully do what I intend.
Could you please test if things still work OK for you with my changes?

vcrhonek commented at 2020-10-26 07:53:¶

@jsmeix
Thank you for improvement of the code, it looks good. Sure, I'll do some tests and let you know.

vcrhonek commented at 2020-10-26 12:59:¶

I've tested and your changes and it works fine, no problem there. But I've found different issue that emerged when multiple keys were defined in LUKS header (this is not done by system installer by default, that's main reason why I've missed it before). I fixed that with additional commit.

jsmeix commented at 2020-10-26 13:03:¶

@vcrhonek
thank you for testing it!

jsmeix commented at 2020-10-26 13:05:¶

@rear/contributors
if there are no objections I would like to merge it tomorrow afternoon
so that users who use our current GitHub master code could test it
and provide early feedback if issues appear for them.

jsmeix commented at 2020-10-28 08:59:¶

Yesterday I found no time to merge is so I will merge it today afternoon.

jsmeix commented at 2020-10-28 11:37:¶

@vcrhonek
thank you for adding initial LUKS2 support to ReaR!

Regarding your question in your initial entry (excerpts)

backup and restore complete LUKS header
users won't lose keys from additional keyslots

In general the ReaR recovery system must be free of secrets
except the user has explicitly configured something different,
cf. the reasoning about SSH_UNPROTECTED_PRIVATE_KEYS in default.conf
https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1523

I don't know about LUKS internals so I don't know if complete LUKS headers
in the ReaR recovery system could contain secrets or could be used
by someone to extract keys relatively easily (e.g. like getting /etc/shadow
from a host so one could do long running cracking attempts to get passwords).

vcrhonek commented at 2020-10-29 08:02:¶

@jsmeix
You're welcome, thank you for your review and improvements!

I see. I don't know much about LUKS internals either. Most of the header is encrypted, but I'm afraid that if someone has copy of it, keys from the header could be used to access the data even if these keys are no longer valid (were removed in more recent version of header). I can ask LUKS experts.

I was thinking to introduce LUKS_HEADER_RESTORE variable that would (when explicitly configured by user) cause usage of luksHeaderBackup/Restore instead of calling luksFormat. I did few tests and it seems to work fine. Please let me know if you think that it would be beneficial, I can contribute the code.

jsmeix commented at 2020-10-29 12:17:¶

Regarding cryptsetup luksHeaderBackup and cryptsetup luksHeaderRestore
the cryptsetup man page (from cryptsetup-2.0.6 in my case) describes it perfectly:

luksHeaderBackup <device> --header-backup-file <file>

Stores a binary backup of the LUKS header and keyslot area.
Note: Using '-' as filename writes the header backup to a file named '-'.
WARNING:
This backup file and a passphrase valid at the time of backup
allows decryption of the LUKS data area, even if the passphrase
was later changed or removed from the LUKS device.
Also note that with a header backup you lose the ability to securely
wipe the LUKS device by just overwriting the header and key-slots.
You either need to securely erase all header backups in addition
or overwrite the encrypted data area as well. The second option
is less secure, as some sectors can survive, e.g. due to defect
management.

I appreciate to introduce a new LUKS_HEADER_RESTORE config variable
that is well described in default.conf (including the information about possible
security issues with header backup files in ReaR recovery system ISOs or media)
and which of course must not be enabled by default.

So I look forward to your subsequent pull requests to further improve LUKS support in ReaR.

jsmeix commented at 2020-10-29 12:46:¶

@vcrhonek
it seems for me the current LUKS2 support does not work as intended.
Currently I use cryptsetup version 2.0.6 on openSUSE Leap 15.1.
For my LUKS2 volume cryptsetup luksDump /dev/sda8 shows

LUKS header information
Version:        2
Epoch:          3
Metadata area:  12288 bytes
UUID:           3e874a28-7415-4f8c-9757-b3f28a96c4d2
Label:          (no label)
Subsystem:      (no subsystem)
Flags:          (no flags)

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

Keyslots:
  0: luks2
        Key:        256 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        PBKDF:      argon2i
        Time cost:  4
        Memory:     1048576
        Threads:    4
        Salt:       49 ea e2 52 22 bd 24 72 2f 88 cf 5f 2a e4 03 76 
                    e1 56 1f d9 dc 0c 41 f8 56 7c c4 26 95 63 4b 86 
        AF stripes: 4000
        Area offset:32768 [bytes]
        Area length:131072 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 130290
        Salt:       9d 14 ba 51 40 ea ee 79 1d 19 32 0a ee a3 dc 41 
                    2d 1e 50 e3 52 17 ef 1b 2f b5 97 8c 1d 77 ae c6 
        Digest:     fd a5 8f f0 7e d4 77 86 06 b9 db e1 3c 09 73 87 
                    4c 06 6f b4 8c 4e 9a 2a 29 05 2e 4b 0f aa f7 53

where the currect code cannot determine the key_size value
because nothing matches grep -m 1 "Cipher key"
and therefore I get in my disklayout.conf

crypt /dev/mapper/luks2test /dev/sda8 type=luks2 cipher=aes-xts-plain64 key_size= hash=sha256 uuid=3e874a28-7415-4f8c-9757-b3f28a96c4d2

I think in my case the right command would be

# cryptsetup luksDump /dev/sda8 | grep -m 1 "Key:" | sed -r 's/^.+:\s*(.+) bits$/\1/'
256

The actual problem with the current code is not that it fails
to parse particular kind of cryptsetup luksDump output.

The actual problem with the current code is that it does not care
when it failed to parse the cryptsetup luksDump output.

This is a general problem with so much code in ReaR
(in particular almost all older code in ReaR is made this way)
that it more or less carelessly and blindly proceeds and does not care
about possible errors, cf. "Try hard to care about possible errors" in
https://github.com/rear/rear/wiki/Coding-Style

In this particular case one would have to check what option values
of the crypt entries in disklayout.conf are needed and for those
there must be basic tests that check whether or not the values
are at least of basically right syntax - e.g. the key_size value
should be a positive integer (that is a multiple of 8),
cf. "man cryptsetup"

--key-size, -s <bits>
Sets key size in bits. The argument has to be a multiple of 8.
The possible key-sizes are limited by the cipher and mode used.
See /proc/crypto for more information.
Note that key-size in /proc/crypto is stated in bytes.

I think it is over the top to verify the key_size value with /proc/crypto
and even a test that it is a multiple of 8 is probably not really needed
to check if the key_size value seems to be OK.

But I think at least something like

is_positive_integer $key_size || Error "..."

should really be added to avoid bad surprises for the user.

This is all based on the assumption that with the code in
usr/share/rear/layout/prepare/GNU/Linux/160_include_luks_code.sh

        case "$key" in
...
            key_size)
                cryptsetup_options+=" --key-size $value"
                ;;

a command like cryptsetup ... --key-size --hash ... with empty key-size value
would let disaster recovery with ReaR fail for the user during "rear recover".

vcrhonek commented at 2020-10-29 13:06:¶

@jsmeix
For my LUKS2 volume it shows:

LUKS header information
Version:        2
Epoch:          3
Metadata area:  16384 [bytes]
Keyslots area:  16744448 [bytes]
UUID:           d3b16848-f4db-4488-9613-19796246175b
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:
  0: luks2
        Key:        512 bits
        Priority:   normal
        Cipher:     aes-xts-plain64
        Cipher key: 512 bits
        PBKDF:      argon2i
        Time cost:  4
        Memory:     1013640
        Threads:    2
        Salt:       74 ab 9e 54 e8 5d 1e 80 a2 02 27 eb c9 f1 d3 7c 
                    0d 97 bf 1b ff 4f ea ce ea ca 49 79 26 89 6a 9f 
        AF stripes: 4000
        AF hash:    sha256
        Area offset:32768 [bytes]
        Area length:258048 [bytes]
        Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
        Hash:       sha256
        Iterations: 132129
        Salt:       1d c8 23 71 e3 7c 92 69 3a 55 61 13 b4 99 6a 4a 
                    19 a5 ca 40 a5 d4 d5 ed fd e4 9c cd 2b 94 b8 44 
        Digest:     54 1e 22 95 9c 58 57 cd b8 90 60 6d 54 a9 37 52 
                    e8 57 32 46 4a 5a e7 46 60 a3 59 fd e7 40 b3 76

I get both 'Key' and 'Cipher key' in header with identical values no matter what I pass to luksFormat. I wasn't able to find good description of the fields so I've chosen the second one. It seems your command is better choice.

Yes, I agree with you, adding checks for correctness of parameters is really needed.

jsmeix commented at 2020-10-29 14:45:¶

@vcrhonek
thank you so much for all your improvement work
that make this old code better and more fail-safe.

jsmeix commented at 2020-10-29 14:47:¶

And this example is a good reason why cryptsetup luksHeaderBackup / luksHeaderRestore
has advantages (for the price of being possibly less secure depending on the user's environment).

jsmeix commented at 2020-10-30 10:44:¶

I verified that things fail for me as I described above in
https://github.com/rear/rear/pull/2504#issuecomment-718729198

With current GitHub master code I get
for rear -D recover this terminal output (excerpts)

Please enter the password for LUKS device luks2test (/dev/sdb2):
...
The disk layout recreation script failed

This is the matching excerpt from the log file
about the actual failure in /var/lib/rear/layout/diskrestore.sh
(long lines shown wrapped here):

+++ Print 'Please enter the password for LUKS device luks2test (/dev/sdb2):'
+++ cryptsetup luksFormat --batch-mode --type luks2 --cipher aes-xts-plain64
 --key-size --hash sha256 --uuid 30376f43-60fd-4fc7-af0c-fad8063d5a1a
 --iter-time 2000 --use-random --force-password /dev/sdb2
Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose]
        [--debug] [-c|--cipher=STRING] [-h|--hash=STRING]
        [-y|--verify-passphrase] [-d|--key-file=STRING]
        [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=BITS]
        [-l|--keyfile-size=bytes] [--keyfile-offset=bytes]
        [--new-keyfile-size=bytes] [--new-keyfile-offset=bytes]
        [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS]
        [-p|--skip=SECTORS] [-r|--readonly] [-q|--batch-mode]
        [-t|--timeout=secs] [--progress-frequency=secs] [-T|--tries=INT]
        [--align-payload=SECTORS] [--header-backup-file=STRING]
        [--use-random] [--use-urandom] [--shared] [--uuid=STRING]
        [--allow-discards] [--header=STRING] [--test-passphrase]
        [--tcrypt-hidden] [--tcrypt-system] [--tcrypt-backup] [--veracrypt]
        [--veracrypt-pim=INT] [--veracrypt-query-pim] [-M|--type=STRING]
        [--force-password] [--perf-same_cpu_crypt]
        [--perf-submit_from_crypt_cpus] [--deferred] [-i|--iter-time=msecs]
        [--pbkdf=STRING] [--pbkdf-memory=kilobytes]
        [--pbkdf-parallel=threads] [--pbkdf-force-iterations=LONG]
        [--priority=STRING] [--disable-locks] [--disable-keyring]
        [-I|--integrity=STRING] [--integrity-no-journal]
        [--integrity-no-wipe] [--token-only] [--token-id=INT]
        [--key-description=STRING] [--sector-size=INT] [--persistent]
        [--label=STRING] [--subsystem=STRING] [--unbound]
        [--json-file=STRING] [OPTION...] <action> <action-specific>
--hash: invalid numeric value

I have LUKS_CRYPTSETUP_OPTIONS+=" --force-password" in my etc/rear/local.conf
(for the reason see the LUKS_CRYPTSETUP_OPTIONS comments in default.conf).

/var/lib/rear/layout/diskrestore.sh runs with set -e - cf. the log (excerpts)

+ source /usr/share/rear/layout/recreate/default/200_run_layout_code.sh
...
++ source /var/lib/rear/layout/diskrestore.sh
+++ LogPrint 'Start system layout restoration.'
...
+++ set -e
+++ set -x

so any non-zero exit code in diskrestore.sh results
that The disk layout recreation script failed.

/var/lib/rear/layout/diskrestore.sh is generated only during rear recover by this script:
https://github.com/rear/rear/blob/master/usr/share/rear/layout/prepare/default/540_generate_device_code.sh

jsmeix commented at 2020-10-30 10:52:¶

With https://github.com/rear/rear/commit/b49a4fc88eeb5a2f065c1109c9219d2fcf76e749
LUKS2 support does now also work with cryptsetup version 2.0.6
(at least it works now for me on openSUSE Leap 15.1).

According to
https://github.com/rear/rear/pull/2504#issuecomment-718740063
it should still work for the systems that @vcrhonek has.

@vcrhonek
please verify that current GitHub master code still works for your systems.
Cf. "Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

jsmeix commented at 2020-10-30 11:33:¶

@mannp @adatum
I would appreciate it when you could test if our LUKS2 support
in our current GitHub master code also works on your systems
cf. "Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
and provide feedback here whether or not things work for you.

mannp commented at 2020-10-30 11:59:¶

@mannp @adatum
I would appreciate it when you could test if our LUKS2 support
in our current GitHub master code also works on your systems
cf. "Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery
and provide feedback here whether or not things work for you.

@jsmeix I was very happy to see the merge for LUKS2 support and installed the git version of rear to give it a try yesterday.

Got sidetracked, but will set aside some time to give it a try :)

jsmeix commented at 2020-10-30 12:35:¶

@mannp
depending on what cryptsetup version you run you may need
https://github.com/rear/rear/commit/b49a4fc88eeb5a2f065c1109c9219d2fcf76e749
which is in the GitHub master code of today.

So I would recommend to better update again to our current GitHub master code.

Perhaps you even use a cryptsetup version where my
https://github.com/rear/rear/commit/b49a4fc88eeb5a2f065c1109c9219d2fcf76e749
does not work and then we would like to know such issues better sooner than later
so that we could make LUKS2 support working with all usual cryptsetup versions.

jsmeix commented at 2020-10-30 14:33:¶

With
https://github.com/rear/rear/commit/d25a1a09dddcbffda802081ea3553c70f9a49c23
I added basic checks to layout/save/GNU/Linux/260_crypt_layout.sh
that the cipher key_size hash uuid values exist.

For me things still work well with that checks.

With artificial causing such errors via

    fi

    key_size=""
    uuid="  "

    if ! test $cipher ; then

in usr/share/rear/layout/save/GNU/Linux/260_crypt_layout.sh
"rear -D mkrescue" fails for me with this terminal output:

# usr/sbin/rear -D mkrescue
...
Creating disk layout
Overwriting existing disk layout file /root/rear.github.master/var/lib/rear/layout/disklayout.conf
Error: No 'key_size' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
Error: No 'uuid' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
Error: No 'key_size' value for LUKS volume luks1test in /dev/sda7
Error: No 'uuid' value for LUKS volume luks1test in /dev/sda7
Error: No 'key_size' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
Error: No 'uuid' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
Error: No 'key_size' value for LUKS volume luks2test in /dev/sda8
Error: No 'uuid' value for LUKS volume luks2test in /dev/sda8
ERROR: Missing LUKS cryptsetup option value in /root/rear.github.master/var/lib/rear/layout/disklayout.conf
Some latest log messages since the last called script 260_crypt_layout.sh:
  2020-10-30 15:27:24.633752720 Error: No 'key_size' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
  2020-10-30 15:27:24.635879887 Error: No 'uuid' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
  2020-10-30 15:27:24.715283297 Error: No 'key_size' value for LUKS volume luks1test in /dev/sda7
  2020-10-30 15:27:24.718042920 Error: No 'uuid' value for LUKS volume luks1test in /dev/sda7
  2020-10-30 15:27:24.800718783 Error: No 'key_size' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
  2020-10-30 15:27:24.804179315 Error: No 'uuid' value for LUKS volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
  2020-10-30 15:27:24.877678147 Error: No 'key_size' value for LUKS volume luks2test in /dev/sda8
  2020-10-30 15:27:24.880293752 Error: No 'uuid' value for LUKS volume luks2test in /dev/sda8
Aborting due to an error, check /root/rear.github.master/var/log/rear/rear-linux-h9wr.log for details

jsmeix commented at 2020-10-30 14:47:¶

And on top of that via
https://github.com/rear/rear/commit/d3e5d15a81536bdfbac43d166a17792d57f7a88b
I made nicer error message texts that contain the LUKS version (i.e. 'LUKS1' or 'LUKS2').
Why not provide info to the user when it is there in ReaR.
It can help him to better distinguish possibly various LUKS volumes that he may have.

With that my above artificial causing such errors lets "rear -D mkrescue" fail
with the following messages on the terminal:

Error: No 'key_size' value for LUKS1 volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
Error: No 'uuid' value for LUKS1 volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part3 in /dev/sda3
Error: No 'key_size' value for LUKS1 volume luks1test in /dev/sda7
Error: No 'uuid' value for LUKS1 volume luks1test in /dev/sda7
Error: No 'key_size' value for LUKS1 volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
Error: No 'uuid' value for LUKS1 volume cr_ata-TOSHIBA_MQ01ABF050_Y2PLP02CT-part2 in /dev/sda2
Error: No 'key_size' value for LUKS2 volume luks2test in /dev/sda8
Error: No 'uuid' value for LUKS2 volume luks2test in /dev/sda8
ERROR: Missing LUKS cryptsetup option value(s) in /root/rear.github.master/var/lib/rear/layout/disklayout.conf

mannp commented at 2020-10-30 16:13:¶

@jsmeix I have not been using rear for a long time so need to configure and test on a spare machine, so it will take me some time to get together :)

I previously was using this on my main machines -> https://aur.archlinux.org/packages/relax-and-recover-git/
Relax-and-Recover 2.6 / Git
Not sure if this pulls in your changes.

vcrhonek commented at 2020-11-02 09:09:¶

@jsmeix I've looked on recent updates and it looks good and works fine on my test machines, thanks!

Have you considered omitting missing values instead of reporting error? Because luksFormat doesn't require any of {cipher, key-size, hash} and if omitted default value is used. Maybe it could omit missing option value and print warning? I'm not saying that I think it would be better, I guess that depends on situation and user preferences.

I was also thinking about 'Key:'/'Cipher key:" issue for second time. If only 'Cipher key:' was present in luksDump, parsing would fail again. I have no idea whether that can happen, to be honest. If that happens, we can match both and use first found like grep -m1 -i "key:" | sed -r 's/^.+:\s*(.+) bits$/\1/'.

But overall, it looks good to me now and I'm looking forward to see results on other setups and distributions.

jsmeix commented at 2020-11-02 11:11:¶

@mannp
to test the current GitHub master code on your system see
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery

That's what I do myself.

I don't know about whatever third-party ReaR packages.
You would have to ask the third-party what their package provides.

jsmeix commented at 2020-11-02 11:30:¶

@vcrhonek
thank you for your sugestions how to further improve the LUKS code in ReaR!

Currently LUKS support (both LUKS1 and LUKS2) is under step by step enhancement
i.e. none of my changes is meant to be an ultimate final state.

I just proceed little step by little step where each little step should keep things working
i.e. I try to not introduce regressions that let things fail that had somehow worked before.

Because at any time a more important issue (e.g. a severe security issue with SUSE
software that I maintain) could appear that gets in my way to move forward with ReaR
so that I can enhance ReaR only little setp by little step where I can pause at any time.

E.g. as long as the LUKS recreation code in usr/share/rear/layout/prepare/
and usr/share/rear/layout/recreate/ depends on cryptsetup option values
we must error out when the usr/share/rear/layout/save/ code fails to get such values.

When the LUKS recreation code in layout/prepare/ was enhanced as a precondition
that it does no longer fail when certain optional cryptsetup option values are missing
then we could no longer error out when the layout/save/ code fails to get such values.

Currently I have time to enhance the LUKS code so I will do some more enhancements
based on your suggestions (but again: only little step by little step).

jsmeix commented at 2020-11-02 12:39:¶

Right now I see the documentation in
https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc
in the section about "Disk layout file syntax" the "LUKS Devices" part is plain wrong
(excerpts - long lines wrapped here):

Square brackets "[" and "]" indicate an optional parameter.
They can be excluded when hand-crafting a layout file line.
...
LUKS Devices

crypt /dev/mapper/<name> <device> [type=<type>]
 [cipher=<cipher>] [key_size=<key size>] [hash=<hash function>]
 [uuid=<uuid>] [keyfile=<keyfile>] [password=<password>]

Actually with the current LUKS recreation code in
layout/prepare/GNU/Linux/160_include_luks_code.sh
only keyfile=<keyfile> and password=<password> are optional.

Fortunately nobody reads documenation so such errors are
totally unimportant in real world practice out there ;-)

jsmeix commented at 2020-11-02 13:38:¶

https://github.com/rear/rear/pull/2506
is my first initial currently untested attempt towards making
recreating LUKS volumes work with optional cryptsetup options

jsmeix commented at 2020-11-03 13:32:¶

@vcrhonek
regarding your https://github.com/rear/rear/pull/2504#issuecomment-720341023
therein (excerpt)

luksFormat doesn't require any of {cipher, key-size, hash}
and if omitted default value is used

Accordingly currently in https://github.com/rear/rear/pull/2506
the cryptsetup options type=<type> and uuid=<uuid>
are still mandatory but I wonder if that is really needed.

How I did set up a LUKS2 volume on a test VM was using plain

cryptsetup luksFormat --type luks2 --force-password /dev/sdb2

cryptsetup luksOpen /dev/sdb2 luks2test

mkfs.ext4 /dev/mapper/luks2test

mkdir /luks2test

mount /dev/mapper/luks2test /luks2test

I need --force-password only because I use weak test passwords.

According to "man cryptsetup"

    luksFormat <device> [<key file>]

the <device> is the only mandatory parameter for cryptseup luksFormat.

So I think we should handle all options optionally in crypt entries in disklayout.conf
except /dev/mapper/<name> and <device>
because <device> is mandatory for cryptsetup
and /dev/mapper/<name> is mandatory for mkfs.

vcrhonek commented at 2020-11-03 14:00:¶

@jsmeix Yes, I agree that type can be optional (still, we probably want to pass it to crypt as we
should be able to get it in layout/save and lately with rear recover we want to recreate the same version of LUKS
that actually was on the machine). But from the point of crypt and cryptsetup luksFormat it is optional.

I'm not sure about uuid though. I didn't try to omit it. It's true that it's not needed by cryptestup luksFormat itself,
but I really don't know ReaR code enough to be sure that it's not needed because of something else (for example, this particular
uuid is referred somewhere else, in some config file or something...). I'm sure you know better:)

I did try to edit disklayout.conf just before I ran rear recover yesterday and replaced
crypt /dev/mapper/luks-d3...5b /dev/vda2 type=luks2 cipher=aes-xts-plain64 key_size=512 hash=sha256 uuid=d3..5b
with crypt /dev/mapper/luks-d3...5b /dev/vda2 uuid=d3...5b (using original code in layout/prepare, without your latest changes applied). The system recovered as expected.

I'll try to save some time tomorrow and look at your recent updates.

jsmeix commented at 2020-11-03 14:19:¶

In https://github.com/rear/rear/pull/2506
I will change the code so that typeand uuid are optional
and try out how things behave for me without any of the optional options.

My primary intent behind is not that "all will just work well"
even without any of the optional options, in particular I think
to recreate a system as if was before all those options should be there.

My primary intent is to not let "rear recover" needlessly fail
if it could have somehow succeed to set up things with default/fallback values.
I think such a "graceful degradation" behaviour could help the user
in case of an emergency disaster recovery more in real world practice.

vcrhonek commented at 2020-11-03 14:28:¶

In #2506

My primary intent is to not let "rear recover" needlessly fail
if it could have somehow succeed to set up things with default/fallback values.
I think such a "graceful degradation" behaviour could help the user
in case of an emergency disaster recovery more in real world practice.

I absolutely agree with that and I had it on mind in first part of https://github.com/rear/rear/pull/2504#issuecomment-720341023

[Export of Github issue for rear/rear.]

#2504 PR merged: Add initial LUKS2 support¶