[pkg-cryptsetup-devel] crypttab keyscript api

[Jonas Meurer]

On 02/09/2009 Ludwig Nussel wrote:
> Jonas Meurer wrote:
> > On 01/09/2009 Ludwig Nussel wrote:
> > > You chose to pass only the value of the keyfile column to the
> > > keyscript. Since the passdev script needs at least information about
> > > device and file you chose to make the argument colon separated. Ie
> > > /dev/foo:/some/file:timeout.
> > > 
> > > What about using the same format as the options column instead for
> > > consistency? ie something like dev=/dev/foo,file=/some/file,timeout=x
> > 
> > the whole keyfile field is given as first and only commandline argument
> > to the keyscript. that way arbitrary new keyscripts can be developed in
> > the future, without any need to change cryptdisks initscripts.
> > 
> > if new options to the options field in crypttab would be required for
> > new keyscripts, maintaining the keyscripts interface would be a
> > nightmare, and custom keyscripts without official support in the
> > distribution would be even harder do implement.
> 
> I'm not suggesting to put options for keyscript in the options
> column. I just wanted to allow a keyscripts to look into the options
> column if it needs to. That way common options like timeout that
> also make sense for keyscripts do not need to be duplicated in the
> keyfile column.

that again would need to introduce a new api to provide the options to
the keyscripts. i agree that there are options which might be useful to
keyscripts, like timeout, tries, ...
one solution that doesn't break backwards compability would be to give
the whole options column wrapped into quotes to the keyscripts as second
commandline argument. but then both arguments to the keyscripts would
contain options. another, maybe even better solution would be to
implement the timeout in cryptdisks initscript directly for keyscripts,
by invoking the keyscript with timeout(1).

> > it seems like you implemented lots similar functions in a slightly
> > different way.
> 
> It's supposed to behave the same for standard cases though. The
> similarity is no accident. When I figured out that some fool
> implemented /etc/crypttab support on SLES10 with an incompatible
> format I went ahead and rewrote it according to the 'specification'
> in the debian manpage.

that's great news. thanks a lot for your work!

> > maybe we could try to unify the code step by step (in a
> > slow process). this would have two benefits at least: more users test
> > the same code (more testing -> more bugs found), and it's easier to
> > develop new features for both distros at the same time.
> 
> Are you sure you want to merge legacy stuff we have to support
> 'forever' due to historical mistakes? (See cryptotab [note the 'o']
> or the hashalot special case).

no, my point was rather to unify code that already does the same but
currently is slightly different between opensuse and debian.

greetings,
 jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20090904/ea9ef357/attachment.pgp>