[arch-projects] [initscripts] next release

Tom Gundersen

4 Nov 2011 4 Nov '11

11:08 p.m.

Hi guys, I plan on making a new initscripts release in the not too distant future, so it would be great if you could all take current master for a spin. The major changes (not so major really): 1) minilogd is now gone. It did not do much (anything?) useful anyway, and was probably broken, but no one seemed to care enough to fix it. This means that we are now arch=any :-) 2) I pushed a few more commits just now that should hopefully help with some shutdown issues (I believe Dave could reproduce some problems, could you have a look if this solves it, if you did not already?). 3) There is a fix for some issues with locale on non-bash shells (zsh in particular). After this I'd hope to clean up cryptsetup. The current state is not good, and there are bugs that have been open against it for a very long time. In particular, we should sort out encrypted swap-devices being created before the random seed is loaded (that is bad...), and the parsing of the crypttab file. The main reason I have not touched the former is that I'm hesitant to change code that could potentially overwrite people's drives with random crap. The reason I haven't touched the latter is that I hate the crypttab format we use. If anyone would like to help (preferably someone who uses any of this), that would be highly appreciated. Cheers, Tom

Show replies by date

Thomas Bächler

5 Nov 5 Nov

1:04 a.m.

Am 04.11.2011 23:08, schrieb Tom Gundersen:

...

The reason I haven't touched the latter is that I hate the crypttab format we use. If anyone would like to help (preferably someone who uses any of this), that would be highly appreciated.

I always planned on dropping the crypttab format and only keep a crypttab parser for legacy systems. Instead, I was planning to have a "one crypto mapping per file" configuration in /etc/cryptsetup.d/ or so, where you would have bash-style KEY=value pairs. This would improve flexibility and extensibility - all the new requested features would be more straight-forward to implement.

Tom Gundersen

10:05 a.m.

On Saturday 05 November 2011 01:04:46 Thomas Bächler wrote:

...

Am 04.11.2011 23:08, schrieb Tom Gundersen:

...
The reason I haven't touched the latter is that I hate the crypttab format we use. If anyone would like to help (preferably someone who uses any of this), that would be highly appreciated.

I always planned on dropping the crypttab format and only keep a crypttab parser for legacy systems. Instead, I was planning to have a "one crypto mapping per file" configuration in /etc/cryptsetup.d/ or so, where you would have bash-style KEY=value pairs. This would improve flexibility and extensibility - all the new requested features would be more straight-forward to implement.

Hm, interesting My issue is with allowing passwords to be written "inline", as well as the fact that we intepret the file as bash rather than plaintext. If we skip those possibilities and move closer to the Debian format from which (I assume) we started, things should be simpler. I also heard that Gnome should soon get support for dealing with the Debian- style crypttab format from a GUI, which we might want to take advantage of (not that I use Gnome, but it sounded neat). I'll do as you suggest and keep the old parser for backwards compatibility though. Cheers, Tom

Thomas Bächler

10:29 a.m.

Am 05.11.2011 10:05, schrieb Tom Gundersen:

...

My issue is with allowing passwords to be written "inline", as well as the fact that we intepret the file as bash rather than plaintext.

When automatically opening volumes, you are not supposed to use passphrases, but keyfiles.

...

If we skip those possibilities and move closer to the Debian format from which (I assume) we started, things should be simpler.

I have no idea what that format is, but there is a shitload of possibilities for crypto, and a "one line per volume" format doesn't seem to cover them all.

...

I also heard that Gnome should soon get support for dealing with the Debian- style crypttab format from a GUI, which we might want to take advantage of (not that I use Gnome, but it sounded neat).

I'd rather have a working format than support for a broken one in a GUI. Why would you need GUI support for crypttab anyway? I don't see the benefit.

Tom Gundersen

6 Nov 6 Nov

12:36 a.m.

On Sat, Nov 5, 2011 at 5:29 PM, Thomas Bächler wrote:

...

Am 05.11.2011 10:05, schrieb Tom Gundersen:

...
My issue is with allowing passwords to be written "inline", as well as the fact that we intepret the file as bash rather than plaintext.

When automatically opening volumes, you are not supposed to use passphrases, but keyfiles.

Yeah, I think I'll add a warning when a passphrase is used. Having looked through it, that should take care of most of my gripes.

...

...
If we skip those possibilities and move closer to the Debian format from which (I assume) we started, things should be simpler.

I have no idea what that format is, but there is a shitload of possibilities for crypto, and a "one line per volume" format doesn't seem to cover them all.

This is Ubuntu's manpage: http://manpages.ubuntu.com/manpages/jaunty/man5/crypttab.5.html. It seems that most distros use something similar to this. I haven't studied what everyone does in detail though. As always, if we are going to change something, I suggest we don't invent our own format but try to see if we can use something that already exists (preferably something that is used by "everyone else").

...

...
I also heard that Gnome should soon get support for dealing with the Debian- style crypttab format from a GUI, which we might want to take advantage of (not that I use Gnome, but it sounded neat).

I'd rather have a working format than support for a broken one in a GUI.

No argument there. The assumption is that the format is not broken :-)

...

Why would you need GUI support for crypttab anyway? I don't see the benefit.

I don't use these kind of tools, but I imagine it would be sensible to integrate this into whatever tool is used to manage/format disks. -t

Heiko Baums

1:18 a.m.

Am Sun, 6 Nov 2011 07:36:30 +0800 schrieb Tom Gundersen :

...

On Sat, Nov 5, 2011 at 5:29 PM, Thomas Bächler wrote:

...
Am 05.11.2011 10:05, schrieb Tom Gundersen:

...
My issue is with allowing passwords to be written "inline", as well as the fact that we intepret the file as bash rather than plaintext.

When automatically opening volumes, you are not supposed to use passphrases, but keyfiles.

Yeah, I think I'll add a warning when a passphrase is used. Having looked through it, that should take care of most of my gripes.

Having passphrases in an unencrypted text file on the harddisk like /etc/crypttab is certainly not the best method. But only offering key files is insufficient. The currently existing methods of storing and entering passphrases or key files must be kept. That implies entering passphrases with the keyboard, storing/reading key files on/from USB sticks and storing/reading keys raw on/from USB sticks with dd must still be possible for every LUKS container. And what's currently missing in /etc/rc.sysinit is a fallback to asking for a passphrase if a key can't be read, e.g. because it has been forgotten to plug in the USB stick. This should be added, too, as it is done in the encrypt hook. I admit I have forgotten to implement it when I've written the rc.sysinit patches for reading the keys from the USB stick. I found it out only recently, and would have written a patch for it in the coming days if you wouldn't want to completely rewrite this cryptsetup system. Tell me, if I shall write this patch anyway. Heiko

Tom Gundersen

2:02 a.m.

Hi Heiko, On Sun, Nov 6, 2011 at 8:18 AM, Heiko Baums wrote:

...

...
Yeah, I think I'll add a warning when a passphrase is used. Having looked through it, that should take care of most of my gripes.

Having passphrases in an unencrypted text file on the harddisk like /etc/crypttab is certainly not the best method. But only offering key files is insufficient. The currently existing methods of storing and entering passphrases or key files must be kept.

Backwards compatibility will be kept. The suggestion was to add a warning if the passphrase is stored inline in /etc/crypttab rather than in a separate file.

...

That implies entering passphrases with the keyboard, storing/reading key files on/from USB sticks and storing/reading keys raw on/from USB sticks with dd must still be possible for every LUKS container.

I agree.

...

And what's currently missing in /etc/rc.sysinit is a fallback to asking for a passphrase if a key can't be read, e.g. because it has been forgotten to plug in the USB stick. This should be added, too, as it is done in the encrypt hook.

That would be very useful.

...

I admit I have forgotten to implement it when I've written the rc.sysinit patches for reading the keys from the USB stick. I found it out only recently, and would have written a patch for it in the coming days if you wouldn't want to completely rewrite this cryptsetup system.

I will probably keep most of the code (I really don't want to touch this stuff), but might have to reorganize a bit (e.g. separate out the swap stuff).

...

Tell me, if I shall write this patch anyway.

The patches would definitely be appreciated, but it would probably make the most sense to wait for the restructuring to hit master so we avoid too many merge conflicts. Cheers, Tom

Thomas Bächler

7 Nov 7 Nov

10:32 a.m.

Am 06.11.2011 01:18, schrieb Heiko Baums:

...

...
...
When automatically opening volumes, you are not supposed to use passphrases, but keyfiles.

Yeah, I think I'll add a warning when a passphrase is used. Having looked through it, that should take care of most of my gripes.

Having passphrases in an unencrypted text file on the harddisk like /etc/crypttab is certainly not the best method. But only offering key files is insufficient.

Nobody talked about removing the "ASK" mode. However, there are problems with parsing passphrases inside crypttab. If you put your passphrase into a separate file, make sure the file has no trailing newline and use that as a keyfile, cryptsetup will treat it as if you entered the passphrase manually. That way, we could phase out passphrase support in favor of keyfiles. (See 'man cryptsetup' for details on the differences between passphrase and keyfile handling)

4558

Age (days ago)

4561

Last active (days ago)

List overview

Download

7 comments

3 participants

participants (3)

Heiko Baums
Thomas Bächler
Tom Gundersen