Oh and one more thing which is a bit unrelated to this, but also a bit
related ;-)
Could you clarify:
tries=<num>
Try to unlock the device <num> before failing. It's particularly
useful when using a passphrase or a keyscript that asks for
interactive input. If you want to disable retries, pass “tries=1”.
Default is “3”. Setting “tries=0” means infinitive retries.
which AFAIU is how often cryptsetup invokes the keyscript and *not* how
often the keyscript itself tries (e.g. asking for a passphrase).
And that's also what should be clarified / "defined", like by saying:
Try to unlock the device <num> before failing. Its how often
the keyscript is invoked when it fails.
If you want to disable retries, pass “tries=1”.
Default is “3”. Setting “tries=0” means infinitive retries.
Note that keyscripts themselves may do their own tries in
addition.
What I describe above makes IMO actually sense, i.e. having two
different kind of tries:
Take my keyscript as an example, which waits for a device, reads a gpg-
enced key from it with passdev, then waits for a passphrase with
askpass and uses that to decrypt the data with gpg.
Currently, when I enter a wrong key (e.g. at boot time) I have to plug
the USB again (retry made by cryptsetup's 4th field tries=0), because
the keyscript exited and the already read stuff is gone.
With an additiones tries=, specific to the keyscript (and set again in
the 3rd field that I abuse so belovedly) I could do the following:
The "internal" tries is e.g. 3, so my own keyscript will already try
reading the passphrase and decrypting the previously read gpg-enced
file 3 times before giving up.
I could surround the asskpass with a timeout, just to make sure that
they keyscipt (with the precious key in memory, allowing for coldboot
attacks) doesn't stay there forever (e.g. if I forgot about the
computer and went shopping).
If the timeout would be e.g. 15s per default, and the internal tries 3,
they keyscript would wait at most 45s... and then exit.
Then the cryptsetup tries=n comes again (for the initramfs it probably
only makes sense with =0), but now, it would need the USB stick again.
Thanks,
Chris.
