[pkg-cryptsetup-devel] Several minor questions (hopefully) ;)

[Jonas Meurer]

Hey Christoph,

First, would you mind closing old and obsolete bugreport #487256? Or do
you still regard it as a valid request?

On 13/12/2008 Christoph Anton Mitterer wrote: 
> I'm still (from time to time) working on some keyscripts for OpenPGP
> encrypted dm-crypt/LUKS-keys and I'd have some minor questions about how
> things are intended to work:

Ok, let's see whether I can help you ...

> 1) The askpass binary, ... is it intended to be always used when entering
> passwords? I mean regardless whether from initramdisk or normal system?
>    Is it guaranteed that it will be always available at the same location
> (/lib/cryptsetup/askpass) for both, initramdisk and normal system?
>    Is it guaranteed that even in future versions of the cryptsetup-package
> you'll include it in the initramdisk via the cryptroot-hook?

Yes, this it's the plan to use askpass for all password prompts, and
yes, askpass is supposed to be available both in initramfs and on the
normal system in the future.

> 2) Can help functions like log_success_msg, panic, etc. also be used from
> keyscripts, and if so from both initramdisk and normal system? (I suppose
> not.)

No, functions like log_sucess_msg, panic, etc. are lsb functions meant
to be used in initscripts, and provided by /lib/lsb/init-functions.
You're free to use /lib/lsb/init-functions for your custom scripts,
though.

> 3) Would it be possible to move the location from the keyscripts within the
> iniramdisk to the same location as in the normal system? I mean from
> /keyscripts/ to /lib/cryptsetup/scripts/. Would be more consistent IMHO,
> and might be of advantage when you look for these files from other scripts
> or so.

I think that the initial reason to change the keyscript diretory was
that the initramfs is meant to be as small as possible, and some extra bytes
for deeper directory structures as well as longer pathnames already do make
a difference here. Not sure about that one though.

> 4) It seems that when I specify something like keyscript=decrypt_ssl in
> crypttab this works from initramdisk, but not from normal system (it
> complains that it doesn't find the script). Could this be a bug? Perhaps
> it's also "related" to 3).

Yes, that's correct. I fixed cryptdisks.functions to search for the
given keyscript in /lib/cryptsetup/scripts now.

> 5) The cryptpassdev hook mentions a mountdev script. I'd like to have a
> look at it but cannot find it :-(

The mountdev.c keyscript was written by David Härdeman. He later renamed
it to passdev.c and obviously forgot to update the cryptpassdev
initramfs hook. I fixed it now. Thanks for pointing that out.

> 6) What's the proper/intended way for hooks to get configuration settings?
>    The idea behind this is the following, I have a hook that adds gnupg to
> the initramdisk and a keyscript that uses it. But there are two versions of
> gnupg (gnupg and gnupg2). In the "near future" these packages will use the
> alternatives mechanism (see bug #503921). Per default I'd like to include
> the gpg selected by the alternatives mechanism but it would be nice to let
> the user force the use of gnupg1 or gnupg2 (regardless of the selected
> alternative).
>    Should I just look for some configuration file in /etc/defaults or do
> you have any better idea?

Sorry, I don't know the proper answer for that question. I doubt that a
"best way" even exists. There are dozens of ways to set defaults for
dozens of different situations. If the gnupg default is stored inside a
file in /etc/defaults, then you should use that one.

> 7) What are the duties of a keyscript? Is it just plain decrypting and
> reporting whether this was successful (exit 0) or not (exit 1) or also
> retries, timeouts, etc? Or is this handled "above"?

That's something to be yet decided. I just completely removed support
for timeouts from cryptdisks initscripts, and initramfs never even
supported it. retries is meant to be used for passphrase input prompts
only.
It doesn't make sense to use either for keyfiles, and it's not decided
yet what to do about keyscripts.
Currently keyscripts are invoked $tries times in case that they file,
but as keyscripts may do any kind of keyfile and/or passphrase
processing, one could argue that supporting retries on a higher level
might be as useless as for keyfiles.
So after all I tend to say that keyscripts need to provide retries
support on their own in case that they depend on passphrase input.

greetings,
 jonas