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.
smime.p7s
Description: S/MIME cryptographic signature
