Odd geli setkey behaviour

In a nutshell:

I wish to create a geli(8) device with two keys: one using a keyfile and no password and one using a password and no keyfile(s). When I create the device using a keyfile and no password, I cannot set the second key. But if I create the device using a password, I can set the second key and also change the first key to a keyfile and no password. Is this normal behaviour? The machine in question runs 9.1-RELEASE, but I think I've seen this before.

More detailed:

This is what I would think should work but doesn't.
Code:
[b]# geli init -s 4096 -e Blowfish -P -K /tmp/test.key /dev/da0[/b]

Metadata backup can be found in /var/backups/da0.eli and
can be restored with the following command:

        # geli restore /var/backups/da0.eli /dev/da0

[b]# geli attach -k /tmp/test.key -p /dev/da0[/b]
Jan 16 16:30:22 ace kernel: GEOM_ELI: Device da0.eli created.
Jan 16 16:30:22 ace kernel: GEOM_ELI: Encryption: Blowfish-CBC 128
Jan 16 16:30:22 ace kernel: GEOM_ELI:     Crypto: software
[b]# geli setkey -n 1 /dev/da0[/b]
Enter new passphrase:
Reenter new passphrase:
[red]geli: Only already defined key can be changed when '-i' option is used.[/red]

This is a bit roundabout but does work.
Code:
[b]# geli init -b -s 4096 -e Blowfish /dev/da0[/b]
Enter new passphrase:
Reenter new passphrase:

Metadata backup can be found in /var/backups/da0.eli and
can be restored with the following command:

        # geli restore /var/backups/da0.eli /dev/da0

[b]# geli attach /dev/da0[/b]
Enter passphrase:
Jan 16 16:41:30 ace kernel: GEOM_ELI: Device da0.eli created.
Jan 16 16:41:30 ace kernel: GEOM_ELI: Encryption: Blowfish-CBC 128
Jan 16 16:41:30 ace kernel: GEOM_ELI:     Crypto: software
[b]# geli setkey -n 1 /dev/da0[/b]
Enter new passphrase:
Reenter new passphrase:
Note, that the master key encrypted with old keys and/or passphrase may still exists[i][sic][/i] in a metadata backup file.
[b]# geli setkey -n 0 -P -K /tmp/test.key /dev/da0[/b]
Note, that the master key encrypted with old keys and/or passphrase may still exists[i][sic][/i] in a metadata backup file.

Any thoughts about why the first method doesn't work but the second does?

Fonz
 
Okay, so apparently everybody is holding up their "Nobody Knows" sign (yes, that's a QI reference). In that case, let me rephrase: "Is this normal behaviour and did I simply miss something obvious, or should I file a PR?"
 
Back
Top