[bug#65002] [PATCH v2 1/2] mapped-devices: Allow unlocking by a key file

[Ludovic Courtès]

Hello!

I know, I know, it’s taken way too long… My apologies!

Tomas Volf <wolf@wolfsden.cz> skribis:

> Requiring the user to input their password in order to unlock a device is not
> always reasonable, so having an option to unlock the device using a key file
> is a nice quality of life change.

Agreed; there’s interest for this feature, I’ve heard it quite a few
times.

> * gnu/system/mapped-devices.scm (luks-device-mapping): New keyword argument
> * gnu/system/mapped-devices.scm (luks-device-mapping-with-options): New
> procedure

No need to repeat the file name here.  Please also mention the
doc/guix.texi changes.

> +@deffn {Procedure} luks-device-mapping-with-options [#:key-file]
> +Return a @code{luks-device-mapping} object, which defines LUKS block
> +device encryption using the @command{cryptsetup} command from the
> +package with the same name.  It relies on the @code{dm-crypt} Linux
> +kernel module.
> +
> +If @code{key-file} is provided, unlocking is first attempted using that
> +key file.  If it fails, password unlock is attempted as well.  Key file
> +is not stored in the store and needs to be available at the specified
> +path at the time of the unlock attempt.

s/specified path/given location/

Perhaps add a sentence or two saying that the advantage is that it
allows you to avoid typing the passphrase, for instance by passing the
key file on a USB key (would that work?), but that this may not be
suitable for all use cases.

I’d also add a short commented config example.

I wonder if we could have a system test; it doesn’t sound very easy so
maybe we’ll skip, but you can check that the “encrypted-root-os” test,
which exercises ‘luks-device-mapping’, still passes (it takes time and
disk space).

The rest LGTM!

Ludo’.