Hi,
I see.
I think back then the idea was to remove the custom key-file feature
entirely--which I didn't want to do (since it has existed in guix
releases).
Yes, /etc/luks_script is only available in the initrd (... overlay). IF
we wanted to then we could copy it out--but I'd rather not by default
(it would retain a passphrase for longer than necessary in the vast
majority of cases).
I have learned (from bitter experience) to not be overly smarty pants in
security. The dumbest most straightforward possible implementation is
the one guix uses.
In this case, Guix's reads /etc/luks_script, finds the entry for the
partition in question, and then tries to open the luks volume using
that. If /etc/luks_script file is missing entirely, it complains since I
don't want to hobble debugging a potential borked bootloader.
This open-luks-device is used by gnu/system/mapped-devices.scm for
opening ANY mapped device, not just at boot. It's also used by
gnu/system/linux-initrd.scm raw-initrd to open it at boot.
That's it.
I can see that if you do already specify a key-file for a specific
volume, you probably want to use that one.
In the end if you have multiple possible mechanisms for the passphrase
(but for example not specify exact which volume that is for), then that
is a policy question. That means all users will end up wanting all
possible combinations of the policy to be implemented.
Your patch makes guix prefer custom key-file to the grub-provided
passphrase, rather than the other way around as it was before.
I have no opinion on whether that is better (except that it happens not
to warn as a side effect of the key-file being used)--but, sure, we can
do that patch :-)
Authentication is a huge can of worms. In an ideal world the user could
specify in config.scm that "use the grub-provided passphrase to unlock
/, then to log into the default user with it and then unlock the gnome
secrets manager with it" or whatever other policy sentence :)
Or smartcards, Bluetooth (non-)proximity alert, HSM and so on.
We could also remove "If /etc/luks_script file is missing entirely, it
complains"--but do we want to? (it exists for the worst case where grub
lost the newc ability or ghosts invaded the computer or any other
unknown unknown)
Or we could check whether we are in the initrd or already booted (can
we, safely? Also, do we want to make it hardcoded policy that the
passphrase doesnt survive beyond the initrd? Or allow the user to
customize the initrd to DO copy it, or do we want an official guix
feature implying that copying to happen etc), and so on.
We should first think of what we want.
Security is one of the things were it is extremely useful to plan first.
Cheers,
Danny
