[Pkg-cryptsetup-devel] Luks

[Jonas Meurer]

On 24/01/2006 gebi at sbox.tugraz.at wrote:
> >too bad, that both of us had the same idea at the same time.
> 
> Yea... it's a nice spare time work to free my head for the exams.

ah, when do you have them? or did you already pass them?

> >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've seen it.
> What things could be checked in precheck?

for example if a partition has already an accessable filesystem, and
therefore cannot be a encrypted one. i know that this is not a very
sensible example, but i implemented it for the swap precheck, because of
bug #342079.
i guess that there are not many useful prechecks, as simply starting
cryptsetup over a partition does not destroy any (important) data, only
writing to the decrypted device (with dd or mkfs) does so.
if i'm correct here, then postchecks are early enough to prevent data
loss, as feared in #342079. and your idea of a swap postcheck is far
more sensible than my ugly attempt to implement a (partially) swap
precheck.

> >is your username gebi, or gebi-guest. i guess that you need --username
> >only once. did you already try it without --non-interactive?
> 
> gebi-guest.
> % svn --username gebi-guest co svn+ssh://svn.debian.org/svn/pkg-cryptsetup
> 
> does not work also
> 
> ssh gebi-guest at svn.debian.org
> does work correctly.
> in ~/.ssh/authorized_keys2 is the correct key.

i experienced similar behaviour when checking out for the first time, it
sometimes asks the password for 3 times and then downloads the tree.
don't ask me why. try the password auth method (without ssh key), and
enter the password three times.

> >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.
> 
> don't be afraid, i'll try hard not to overwrite any of your changes.
> only merging ;).

sounds reasonable ;-)

> >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?
> 
> yaird is 2.6only, but should be no problem.
> But i don't know what's the stage of initramfs-tools.

as far as i know, initramfs-tools is 2.6only too, but still no problem
to support one or both of them.
if we really need mkinitrd support later, we still can develop it, but
now let's focus on other tasks.

> >yes, that's a great problem. how could we provide upgrade functionality?
> 
> imho thats not possible.
> 
> >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?
> 
> This methode was really dangerous. Because you have only _ONE_ run.  
> I'v you have any problems in the first run your fs will be messed up.
> 
> >if yes, we could provide some script-magic to do this at upgrade time,
> 
> Absolutly impossibel.
> What about users with 1TB array. And thats not that uncommon.

you're correct, providing automatic upgrades is impossible. so the only
solution will be to abort installations when upgrading from earlier
versions of cryptsetup, and ask the user to to the migration by hand
(i.e. temporarily copy the encrypted data into an uncrypted device).

what we could provide, is to copy a staticly linked /sbin/cryptsetup into
another location (i.e. /sbin/cryptsetup-1.0.2) and then abort the
installation. sysadmins could use this new binary to create recent LUKS-
encrypted devices and then continue the installation.

best would be to require manual interaction (like a empty touched file
at /etc/cryptsetup-continue-installation) before really doing the
upgrade to the new debian package.

> >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.
> 
> My hope is, that the new LUKS will retain compatibility with older  
> ondisk layouts.

this would indeed be the best.

> >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?
> 
> It does not have the "same" functionnality. It's an other level of  
> creating doku. You could create many formats out of asciidoc (even  
> docbook).
> 
> _asciidoc source_: http://einsteinmg.dyndns.org/projects/grml/grml-vpn.8.txt
> docbook xml: http://einsteinmg.dyndns.org/projects/grml/grml-vpn.8.xml
> [...]
> It's just fun to write asciidoc doku :)!!

asciidoc looks great, go ahead with the doc transition if you like.

> >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:
> 
> I should make a postit about dch -a. Thats what i forget much to often :(.

yes, especially when you sit the whole day in front of the monitor and
improve functionality, fix bugs, etc. and at the end you don't know any
more what you did.
in these situations a diff with previous versions is often the only
information that helps.

...
 jonas