[Debburn-devel] Crypto support in cdrkit

[Eduard Bloch]

#include <hallo.h>
* Reinhard Tartler [Fri, Feb 09 2007, 01:06:27PM]:
> Eduard Bloch <edi at gmx.de> writes:
> 
> >> [1] http://burbon04.gmxhome.de/linux/CDREncryption.html
> >
> > Originaly, I disagreed adding it because of not seeing any good point
> > therein. It only adds additional complexity to wodim, but for which
> > purpose? What exactly can you do with it that you cannot do with a
> > wrapper script around genisoimage which uses aespipe &Co.?
> 
> Exactly this question is answered in lenght on the webpage linked in [1]
> above, see section "Why ? And why a patch for cdrecord ?". What You
> propose sounds like point 2: "completely in userland, encrypting the ISO
> and burn it the usual way". The patch in question attempts point 5
> "between userland and kernel".

Yes, and? When I continue reading his complaints about "the complicated
things" I fail to see a perfect solution in his patch either. Even
assuming that we would add the encryption (which seems to be quite
feasible without additional dependencies), there I things I do not like
in the current solution:

 - reading the password is not really nice. The command line arguments
   can be seen by other users. The only good way around it is a cludge
   with a FIFO file where a command (eg. ssh-askpass) writes the
   passphrase into. IMO the extentsion should use just one specified
   command and nothing more.
 
 - Transparency: all configuration is done with command line options...
   that sucks, that does not make the extension more transparent than the
   things complained about (wrappers).
 
 - what is the patch good for? Only data. Then what is it doing in
   cdrecord and is not implemented as part of mkisofs instead?

I can imagine implementing this things as part of genisoimage. Calling a
passphrase interaction command that you specify in an environment
variable of .genisoimagerc. And the encryption options. Or maybe both of
them... imagine having a simple GUI called by genisoimagerc which asks
you to set the parameters (using buttons) and insert the password twice.
I think implementing it that way is quite feasible by reusing the code
from the CDRencryption patch and ssh-askpass-gnome utility.

And having this kind of thing in genisoimage would allow you to do
encryption spanned over multiple isofs sessions (when using
multisession) in a more user-friendly way. And it would allow to use it
with growisofs, and maybe other tools.

> More specifically, this patch creates a LUKS header on the image. I'm
> not aware of any pipe like wrapper which supports LUKS. [2]
> 
> [2] http://luks.endorphin.org/

Oh no, that's enough. Please go and read the pages you are refering to. Now.

Because I cannot discover the header construction described in
http://luks.endorphin.org/LUKS-on-disk-format.pdf in the code of that
patch, and, uhm, the page itself says:

The ToDo-list for a new version includes support for more key lengths and maybe even LUKS support to
                            allow better (i.e. easier) integration into desktop managers. And I think I will put the current 1.0 into
                            some kind of standalone tool - for those who still prefer piping and encrypting outside of cdrecord ;-))

And TODO-List != implementation != mature implementation.

Eduard.

-- 
<Karat3> wie führt man noch mal ein shellscript aus?
<Ganneff> ausdrucken, einstecken, zum italiener gehen, auf nen stuhl legen
<alphascorpii> ... und sag ihm ein paar nette Sachen, das mögen sie