Show disklayout.conf and diskrestore.sh content in "rear -D recover" log

[jsmeix]

Basically always when there is a user report where "rear recover" failed
I would like to see the user's disklayout.conf and diskrestore.sh
to have it easier to imagine what goes on on the user's system.

Therefore I would like to print the disklayout.conf and diskrestore.sh content
into the "rear -D recover" log (i.e. only in case of debugscript mode).

What I worry about is that disklayout.conf and diskrestore.sh
can contain secrets, e.g. "Disk layout file syntax" in
https://github.com/rear/rear/blob/master/doc/user-guide/06-layout-configuration.adoc
reads (excerpt)

LUKS Devices
crypt ... [cipher=<cipher>] ... [password=<password>]
...
TCG Opal 2-compliant Self-Encrypting Disks
opaldisk ... [password=<password>]

which means the "rear -D recover" log can contain secrets, cf.
#2156

On the other hand I assume that currently the "rear -D recover" log
may already contain the cipher and password values for LUKS
and/or TCG Opal 2-compliant Self-Encrypting Disks
via the normal set -x output.

[jsmeix]

@OliverO2
FYI see this issue #2285
because it is also about that ReaR's debugscript log may contain
the password value for TCG Opal 2-compliant Self-Encrypting Disks
via the set -x output, cf. #2156

[OliverO2]

@jsmeix
I just had a short look, but to me it seems like the password is protected from appearing in the log:

rear/usr/share/rear/layout/prepare/GNU/Linux/180_include_opaldisk_code.sh

Line 55 in 307f1f3

echo "# Protect against passwords appearing in the log file"

[jsmeix]

@OliverO2
from plain looking at the code of the create_opaldisk function
I think it only switches off set -x inside diskrestore.sh
while the confidential commands are running
but I think it does not redirect stderr to /dev/null
while the create_opaldisk function is running.
So I think set -x output may appear in the log
while create_opaldisk is running.

On the other hand it seems $OPAL_DISK_PASSWORD
is nowhere evaluated while the create_opaldisk function is running
because it is always used as \$OPAL_DISK_PASSWORD so that
$OPAL_DISK_PASSWORD is only evaluated while diskrestore.sh
is running and there set -x is switched off.

But I found unescaped $OPAL_DISK_PASSWORD
several times in various functions in
usr/share/rear/lib/opaladmin-workflow.sh

On first glance I cannot see whether or not set -x could be set
while those functions are running.

[OliverO2]

Yes, the opaladmin workflow contains no special debugscripts protection. But this is an isolated workflow which does not interfere with the rest of ReaR.

If a need should arise to debug this workflow with -x and send out the log, the user should use demo passwords only or scrutinize the log for any production password used.

[github-actions]

Stale issue message