[Pkg-cryptsetup-devel] gpg support for cryptsetup and decrypt_* scripts

[David Härdeman]

On Mon, February 18, 2008 23:00, Christoph Anton Mitterer wrote:
> Ok... in this case I agree with you idea, to require that each scrip
> provides a command line parameter (e.g. "--print-deps") that prints the
> dependencies.
> For backward compatibility one could make two passes,... if the
> invokation with --print-deps fails,.. automatic dependency collection is
> simply disabled.

I've considered that, but it doesn't guarantee backward
compatibility...the script might simply hang forever waiting for some kind
of input whether it is executed with or without the command line parameter
(or the env parameter for that matter). The advantage of the env parameter
is that argv handling doesn't need to change for the scripts.

>> Yes, something like that...the problem is that the switch would still be
>> difficult to perform since it could still break with old scripts.
>>
> Well,.. but is this so critical? The change could be added to the NEWS,
> and I think dm-crypt root filesystems are mostly used by paranoid freaks
> like me XD,... these people should easily be able to adapt there
> scripts.

We probably have to implement it with *some* user visible changes...so it
will probably have to be communicated via NEWS, yes. But we can at least
minimize the problems.

> The most easiest thing is probably to use /dev/tty instead of writing to
> stderr (of course only if this make sense). So I think errors (like
> "\nMaximum number of attempts exceeded") should obviously be written to
> stderr, but what's with informal messages like
> "\nDecrypting ssl key $1..."?

I'm not sure what you're talking about now...how the gpg keyscript should
handle input/output in initramfs? If you're not interested in supporting
usplash, it should be enough to redirect stdin, stdout and stderr to
/dev/console (if we're talking about a initramfs script). If you're
talking about something else I need clarification :)

-- 
David Härdeman