Am 22.03.2012 23:22, schrieb Matthew Monaco:
Since we're going for systemd compatibility
We are?
we're going to need to change the key syntax.
You have a strange idea of what we NEED to do.
It seems like there are two supported syntaxes which are handled a little bit differently by the encrypt hook and initscripts.
1) <dev>:<fstype>:<file>
I want to support this by adding a keydev= option.
We have an option for this. Is there any sane reason to change it?
What remains is what to do when a key is not available and there is no keydev=. For a first go I think such a setup doesn't need to be supported, but eventually deriving a default will be good.
I have no idea what you are talking about. Please, make some sense.
The primary target here is to support having a keyfile for an encrypted /usr stored on root. This is a little tricky in the initcpio because it would be pretty undesirable from my perspective to tell the user such keys need to be /new_root/...
I made it a point not to support such setups - people need to do sane things when doing encryption - this doesn't sound sane.
One way to do this would be keydev=/dev/mapper/root, but this might mean mounting root to some temporary location, unmounting it, and then having initcpio pick up as normal after the hooks. Among other things, this would mount root before fsck.
If you really want to support this, you need to go further - you need to change more of the architecture in early userspace.
2) <dev>:<offset>:<length>
I want to drop support for this. The length field is supported by cryptsetup's --keyfile-size option.
You actually have no idea how this is supposed to be used. You can store a key on a USB drive in the unused space between partition table and the first partition. This way, you can store a key without anyone noticing it is there.
I don't see <offset> being widely used as its not even documented.
It is used in the wild, I am pretty sure of this.
Coupled with systemd not supporting anything like this, I'd like to cowardly refuse to implement it.
Yes. First we start implementing things because systemd implements them. And now, we stop supporting things because systemd doesn't support them. What are we, the slaves of the systemd imperium? It seems like I lack some context here. But as you start your mail without any context, it is clear you were not planning to give any. What is the motivation for this mail and where do all these things we need to and don't need to do come from? Now the important part: Keeping a broken, unsuitable and non-standardized format like crypttab is plain stupid. A one-line-per-container file format cannot even begin to contain all the options that people want to use. Over the years, people wanted to: 1) Open containers via passphrase. 2) Open containers via keyfiles. 3) Open containers by using raw areas on block devices of all kinds. 4) Use random keys to create a new container and a) Create a swap space on it b) Create a fresh file system on it and mount that somewhere Those are just the things I remember off the top of my head, I am pretty sure there was more. And you are planning to push this all into the one-line-per-container crypttab. Even worse, you are planning to drop some already existing features, because you CAN'T put them all into that format. A proper way to solve this would be a directory with proper configuration files, one file per container. You would then be free to support all interesting options and have enough flexibility to add more options later. Staying with crypttab will only give you a half-baked solution, and you will end up having to close most feature requests you get, because extending the format will be nothing but a pain in the ass.