[Pkg-cryptsetup-devel] Luks

[gebi at sbox.tugraz.at]

Hi,

> so you uploaded 1.0.1-8 to your apt repository?

yes
is this a problem?

> i started with merging
> the debian stuff from cryptsetup and cryptsetup-luks, and released the
> cryptsetup-luks package as 1.0.1-8 too.

*gg* nice ...

> afterwards i merged both into one cryptsetup package, added the new
> precheck, postcheck and retry options to the cryptdisks initscript and
> fixed several other bugs from the bts.

I've added luks support to the init script a few versions ago.

> i checkout and commit stuff from/to svn.debian.org via svn+ssh.

% svn --username gebi-guest co --non-interactive --username 'gebi'  
svn+ssh://svn.debian.org/pkg-cryptsetup
Enter passphrase for key '/home/einstein/.ssh/id_rsa':
Password: <pw><enter>

does not work here :(.

> please merge the patch and your other changes (from 1.0.1-8) into the
> 2:1.0.1-13 package from alioth.
> this one has lots of improvments and bugfixes.

ok

> > I'll try to put it in the svn at night.
> please don't overwrite the cryptsetup trunk.

overwrite?
I thought about simply adding the "changes" to trunk.
The -q/--batch-mode patch is a dpatch fragment (patches/02_batch-mode.dpatch).

> next things would be to improve the cryptoroot and usbcrypto
> documentation and to provide better support for initrd/initramfs.

Yaird allready has support for cryptsetup-luks (we are using it with  
our distribution grml.org).
And a few small fixes for CryptoSwap.howto (no one wants to reboot his  
computer for any other things than kernel upgrades).
A simple swapoff -a; <setup cryptoswap>; swapon -a and everything is working.

> also the support for keys on removable media could be improved.

Yes /bin/xor is imho not really the right encryption for the keys on  
the media ;). Am i right, that usbcrypto.mkinitrd does only work with  
devfs?
Similar problem with usbcrypto.hotplug, there is no hotplug anymore.

> and the (upstream relating) bug in debian bts regarding the missleading
> error messages of cryptsetup (http://bugs.debian.org/258376)

I don't know if upstream ever fixes this issue but i thought not.

What makes me more headache is the ondisk layout change coming with  
the next version of luks :( (one logical change + add a backup luks  
header at the end of the partition, imho).

If we ever want to enhance the .sgml docu we should first convert it  
to asciidoc, it's only a matter of minutes and writing asciidoc is  
many times faster then sgml.

ps.:
ok how should we coordinate our efforts in the svn?
I don't want to mess up the svn, so adding new files, commiting new  
versions should be no problem, but i should avoid  
branching/tagging/merging in the near feature ;) (im a heavy mercurial  
user).

eg. where should i commit my dpatch fragment for the -q/--batch-mode?
svn co ...
cd cryptsetup/trunk/debian
cp 02_batch-mode.dpatch patches
echo 02_batch-mode.dpatch >>patches/00list
svn commit -m 'added 02_batch-mode.dpatch to support --batch-mode'

somthing like this?

greets,
Michael Gebetsroither