<p><br>
On Mar 22, 2012 11:57 PM, "Thomas Bächler" <<a href="mailto:thomas@archlinux.org">thomas@archlinux.org</a>> wrote:<br>
><br>
> Am 22.03.2012 23:22, schrieb Matthew Monaco:<br>
> > Since we're going for systemd compatibility<br>
><br>
> We are?<br>
><br>
> > we're going to need to change the<br>
> > key syntax.<br>
><br>
> You have a strange idea of what we NEED to do.</p>
<p>Some context is indeed missing. Matt and I have discussed this off list. This is a summary of my position:</p>
<p>We should refactor the crypttab handling in initscripts. In particular in order to be able to load our random seed before using urandom.</p>
<p>We should absolutely not add config options that are not supported by at least one other major distro (e.g. Debian), and we should try to avoid adding config options that are not supported by ALL major distros (c.f. systemd).</p>
<p>We should support all current usecases, but I'd be inclined to drop passphrase support in favor of keyfiles, and to move esoteric setups (such as usb devices with offsets) into initscripts hooks.<br></p>
<p>> > It seems like there are two supported syntaxes which are handled a<br>
> > little bit differently by the encrypt hook and initscripts.<br>
> ><br>
> > 1) <dev>:<fstype>:<file><br>
> ><br>
> > I want to support this by adding a keydev= option.<br>
><br>
> We have an option for this. Is there any sane reason to change it?<br>
><br>
> > What remains is what to<br>
> > do when a key is not available and there is no keydev=. For a first go I<br>
> > think such a setup doesn't need to be supported, but eventually deriving a<br>
> > default will be good.<br>
><br>
> I have no idea what you are talking about. Please, make some sense.<br>
><br>
> > The primary target here is to support having a keyfile for an encrypted /usr<br>
> > stored on root. This is a little tricky in the initcpio because it would be<br>
> > pretty undesirable from my perspective to tell the user such keys need to be<br>
> > /new_root/...<br>
><br>
> I made it a point not to support such setups - people need to do sane<br>
> things when doing encryption - this doesn't sound sane.<br>
><br>
> > One way to do this would be keydev=/dev/mapper/root, but this might mean<br>
> > mounting root to some temporary location, unmounting it, and then having<br>
> > initcpio pick up as normal after the hooks. Among other things, this would<br>
> > mount root before fsck.<br>
><br>
> If you really want to support this, you need to go further - you need to<br>
> change more of the architecture in early userspace.<br>
><br>
> > 2) <dev>:<offset>:<length><br>
> ><br>
> > I want to drop support for this. The length field is supported by<br>
> > cryptsetup's --keyfile-size option.<br>
><br>
> You actually have no idea how this is supposed to be used. You can store<br>
> a key on a USB drive in the unused space between partition table and the<br>
> first partition. This way, you can store a key without anyone noticing<br>
> it is there.<br>
><br>
> > I don't see <offset> being widely used as its not even documented.<br>
><br>
> It is used in the wild, I am pretty sure of this.<br>
><br>
> > Coupled<br>
> > with systemd not supporting anything like this, I'd like to cowardly refuse<br>
> > to implement it.<br>
><br>
> Yes. First we start implementing things because systemd implements them.<br>
> And now, we stop supporting things because systemd doesn't support them.<br>
> What are we, the slaves of the systemd imperium?</p>
<p>No. This is not a valid reason to drop something.</p>
<p>> It seems like I lack some context here. But as you start your mail<br>
> without any context, it is clear you were not planning to give any. What<br>
> is the motivation for this mail and where do all these things we need to<br>
> and don't need to do come from?<br>
><br>
><br>
> Now the important part: Keeping a broken, unsuitable and<br>
> non-standardized format like crypttab is plain stupid. A<br>
> one-line-per-container file format cannot even begin to contain all the<br>
> options that people want to use.</p>
<p>I dont see the problem. We essrntially describe graph, fstab and crypttab describing the edges and the blockdevices being thr vertices.</p>
<p>We should strive to use standard fotmat accross all distros, but except for that I dont see a major ptoblem with the current state of affairs.</p>
<p>> Over the years, people wanted to:<br>
> 1) Open containers via passphrase.<br>
> 2) Open containers via keyfiles.</p>
<p>These two are essrntially the same.</p>
<p>> 3) Open containers by using raw areas on block devices of all kinds.</p>
<p>If there is no offset, this is the same as 1+2, otherwise some trickery is needed.</p>
<p>> 4) Use random keys to create a new container and</p>
<p>Thats the same as 1+2, with the exception that we ought to initialize our rsndom pool first.</p>
<p>> a) Create a swap space on it</p>
<p>Yup.</p>
<p>> b) Create a fresh file system on it and mount that somewhere</p>
<p>All distros support this, but i dont get the point.</p>
<p>> Those are just the things I remember off the top of my head, I am pretty<br>
> sure there was more. And you are planning to push this all into the<br>
> one-line-per-container crypttab. Even worse, you are planning to drop<br>
> some already existing features, because you CAN'T put them all into that<br>
> format.</p>
<p>One-line is not a problem. Im not aware of any additional feature requests, does anyone else have anything?</p>
<p>> A proper way to solve this would be a directory with proper<br>
> configuration files, one file per container. You would then be free to<br>
> support all interesting options and have enough flexibility to add more<br>
> options later.<br>
><br>
> Staying with crypttab will only give you a half-baked solution, and you<br>
> will end up having to close most feature requests you get, because<br>
> extending the format will be nothing but a pain in the ass.<br>
><br>
</p>