[Pkg-cryptsetup-devel] Luks

[Jonas Meurer]

On 23/01/2006 gebi at sbox.tugraz.at wrote:
> >so you uploaded 1.0.1-8 to your apt repository?
> 
> yes
> is this a problem?

no, no 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 ...

too bad, that both of us had the same idea at the same time.

> >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.

yes, but i don't mean luks support. i've merged cryptdisks from
cryptsetup and cryptsetup-luks, and added support for new options
(precheck, postcheck and retry) to it.

> >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 :(.

is your username gebi, or gebi-guest. i guess that you need --username
only once. did you already try it without --non-interactive?

> >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).

yes, that's ok. but when you would remove a current script and commit
your own version, then you would negotate my commitments. that's what i
wanted to prevent.

> >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.

great, maybe you commit the improvements for CryptoSwap.howto into the
svn (don't forget to mention them in the changelog), and write some
short howto about how to use yaird. if this works, we could simply drop
documentation/support for mkinitrd, don't you think so?

> >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.

i've never used the usbcrypto.* stuff, so no idea about that. but in
case that you're correct, it really has to be improved, as devfs is
obsolete.

> >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.

nevertheless it is a (wishlist) bug in cryptsetup, and i'dd like to see
it fixed too. if upstream refuses to fix it, we could provide a patch,
and leave it up to upstreams decision what to do with it upstream. we
could include it nevertheless.

> 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).

yes, that's a great problem. how could we provide upgrade functionality?
in the past there was a way to encrypt partitions on the fly, without
copying the data out of the partition. is this still possible with luks?
if yes, we could provide some script-magic to do this at upgrade time,
if not we need to print a strong warning at upgrade time, with the
information that upgrades should be aborted now, and only be continued
after all data is backuped on non-luks filesystems. we could provide a
script to automaticly copy data from encrypted devices to another
place that can be choosen by the admin, reformat the luks-device and
afterwards move the data back onto the encrypted device.

> 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.

sounds reasonable. i've never worked with asciidoc so far, but if it has
the same functionality as sgml (easy manpage creation etc.) i've no
objections. what about xml?

> 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).

yes, simply commit your changes into the trunk.
but if you start a new development line, like a big change that will
break functionality in the beginning, please copy the trunk to another
branch first, and work on the branch, like:
$ svn co .../pkg-cryptsetup/cryptsetup
$ cd pkg-cryptsetup/cryptsetup/
$ svn copy trunk branches/new-feature
$ cd branches/new-feature
$ [ do whatever you want ]
$ svn commit -m "added the great new feature"

> 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'

yes, almost correct. only 'dch -a' for adding the changelog entry and
'svn add' for adding the file to svn is missing. second, the list at
debian/patches/00list needs the patch names without their .dpatch
ending. so you should do the following:

$ svn checkout .../cryptsetup
$ cd cryptsetup/trunk
$ cp /path/to/02_batch-mode.dpatch debian/patches
$ echo 02_batch-mode >> debian/patches/00list
$ dch -a
$ svn add debian/patches/02_batch-mode.dpatch
$ svn commit -m "added 02_batch-mode.dpatch to support --batch-mode"

...
 jonas