[pkg-cryptsetup-devel] Bug#560034: Bug#560034: Bug#560034: marked as done (please include the "Cryptsetup OpenPGP Scripts")

[Christoph Anton Mitterer]

On Thu, 2010-03-04 at 17:42 +0100, Jonas Meurer wrote:
> i just took the time to write an own implmentation, heavily based on the
> patch you sent.

> only feature that is missing, is support for passdev in
> the keyscript.
Well.... I'd say this is THE imporant part of the whole thing, isn't it?
If one puts so much effort in securing the system it's usually also a
MUST HAVE to keep the keys on a mobile device (USB stick).


> but i believe that a simple decrypt_gnupg without passdev
> is the proper way to go.
Do you? I mean as long as there is no "chaining-framework" provided by
cryptsetup to chain several keyscripts like "first do a passdev then
take this and do decrypt_something"..


> everybody is free to write custom keyscripts
> which simply combine existing default keyscripts.
Of course,.. but this is not the case for end users... And even
"experts" (I mean people with enough skill to find the scripts and cat
them togehter) are not automatically suited to produce _secure_
keyscripts.


>  but that's the way to
> go, instead of adding i.e. passdev support to every single keyscript.
I don't want to start this discussion again,.. but I fear that you'll
have to accept at some point that keyscripts have to be more mightier as
the current small 10-20 lines scripts... at least if you want to provide
people with powerfull stuff.


> you set many values for gpg, while i believe that the default
> values are best.
--quiet --no-verbose --no-greeting
=> Do not bother the user with unneeded output...
I mean we take so much efforts to do things liky splashy and that like
to make the boot process nices,... why should we print things like GPG'
copyright?

--batch
=> Definitely suggested whenever using gpg in a script...

--no-options --no-random-seed-file --no-default-keyring
--keyring /dev/null --secret-keyring /dev/null --trustdb-name /dev/null
=> All of them simply mean, do not create any files which we don't need
anyway (including all that stuff in ~/.gnupg).
When using the keyscript "outside" of the initramfs this would be
created in /root/ and perhaps mess up with existing things or setups,
who knows.

--passphrase-fd 0
=> 1) I think all passphrase input in cryptsetup's keyscripts should use
askpass,... as a central point to (later) support things like splashy.
=> 2) At least when I tried it, gpg was not able to create a tty or so,
when run "within" the initramfs boot process. Even with deprecated
options like --no-tty an so.... askpass was the only why to get this.
As I definitely wanted support to get the key material from different
sources (passdev/directly) this was the only way to still enter the
passphrase.

--decrypt
Obviously required...


>  if they ever change, nobody remembers to change them in
> the keyscript as well.
Admittedly, but that's _always_ a problem...



> i would be very happy if you could take a look at my implementation.
> maybe you're even able to write a simple wrapper keyscript which
> combines passdev and decrypt_gnupg to have the same functionality as
> your original decrypt_openpgp keyscript.
Is this wrapping stuff really a cleaner approach than have a single more
powerful script?


> you can find my implementation in the cryptsetup svn trunk.
I'll see when I have time,... next week I give a course for some
students...



I think it might be worth to thing about providing a
crpytsetup-extra-keyscripts package or so...

You see it's really difficult to get new scripts into especially if
there are people who'd like to see even more complicated stuff, like
support for OpenPGP SmartCard, or
get-the-key-from-some-secure-network-link or whatever...
Or other people might even use binaries for this task,.. and want to see
fancy animations during the decryption process or so ^^

You could keep some basic standard keyscripts which you're the
"maintainer" for in the main-package, and put all other stuff, like
mine, in the separate package.
And put the maintaining-duty on the respective authors.

At least I had always intended to keep my script-suite maintained and I
did not want to put this on you.
There should be little harm for your with such an approach


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3387 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20100304/8cee0c0e/attachment.bin>