trying to run "geli setkey -n 1 gpt/hd01" on a detached geli provider asks me for the master password, and after entering the right password just prints "Note, that the master key encrypted with old keys and/or passphrase may still exists in a metadata backup file." - so it does not ask me for the userpassword I want to set to slot 1 (as one woud expect). So either the man page should be changed to inform the user that setkey only works with attached providers or the program should be adapted so that after entering the right master password the user is asked for the user password. (IIRC this has already worked the last time - quite some time ago - when I used it)
"geli setkey -n 1 gpt/hd01" works when the provider is already attached - the dialogue:
Enter new passphrase:
Reenter new passphrase:
Note, that the master key encrypted with old keys and/or passphrase may still exists in a metadata backup file.
System: FreeBSD mach2020 12.2-RELEASE-p6 FreeBSD 12.2-RELEASE-p6 GENERIC amd64
same behaviour on 13.0-RC5
I can confirm this bug. It exists in 12.2-RELEASE-p6 and 13.0-RELEASE, but _not_ in 11.4-RELEASE-p9.
Steps to reproduce:
# mdconfig -a -t malloc -s 10M -u md10
# echo aaa | geli init -J - md10
# echo aaa | geli attach -j - md10
# geli status md10.eli
# geli detach md10
At this point, md10 is a geli volume with passphrase "aaa". Now, observe the failure of geli setkey:
# geli setkey -n0 md10
This command asks for the existing passphrase and then does nothing. It _should_ ask for the new passphrase (and correctly does so on 11.4-RELEASE).
The same happens when using passfiles:
# echo aaa > oldkey
# echo bbb > newkey
# geli setkey -n0 -j oldkey -J newkey md10
At this point, "aaa" is still the passphrase in slot 1 of md10.eli, even though it should be "bbb". Confirm this by:
# geli attach -j newkey md10
... which fails, and:
# geli attach -j oldkey md10
... which succeeds (but shouldn't).
Note that all is well when using geli setkey on md10.eli when it is attached. This bug only affect unattached volumes.