On Mon, Jun 05, 2006 at 11:38:32AM -0400, [EMAIL PROTECTED] wrote:
(Your e-mail to me here wasn't Cc'ed to the bug itself -- i'm not sure
whether that was intentional or not, but i'm not replying to the bug
myself to avoid sending private correspondence to a public place.
However, i have no problem if you decide this exchange belongs on the
bug, and want to post these replies there.)
That was an oversight, I'm CC:ing this reply to the bug including most
of the text for context.
On June 5, [EMAIL PROTECTED] said:
Now that I've thought over this a bit more, I think this is the
wrong way to go. The initramfs hook should probably complain if no
options are set in /etc/crypttab and the manpage should be changed
to state that the options are mandatory.
The reason is that the defaults can change
(i.e. aes-cbc-essiv:sha256 will become the default in the next
release). If they do, and you haven't set up the options in
crypttab you'll end up with unmountable partitions and possibly a
non-working initramfs.
Ouch! I can understand why you'd want to change the defaults in
cryptsetup (better algorithms, longer key lengths, etc), but i can
also see the massive problems that might cause. Imagine someone who
went with the defaults at some point in the past, and expects to be
able to get back into the block device with a simple "cryptsetup
create" from the new version of cryptsetup. This is true for any
crypted partition, whether root or not. i hope that at least you'll
add a mention of this change to NEWS.gz; it certainly merits it.
The notion of using the default also implies that the default might
change over time IMHO.
But I do agree that it should be mentioned in NEWS.gz.
This is where LUKS really shines, i think, because the partition
records all this stuff. But in the non-LUKS case... yikes!
Yup
Given the change in the defaults, i certainly think requiring explicit
values in /etc/crypttab is reasonable (though i don't think it should
just be required for the root partition either).
Agreed, it should be required for everything and documented as such in the
man page. I expect that this will be fixed in the version after the next
one.
Are initramfs hook scripts allowed to abort the initramfs build
process? or to request user input? How can the hook script cope with
the case where some of the 3 options are *not* present?
The hook can abort the build simply by doing something like:
echo "Parameter missing" >&2
exit 1
I'll take a look at implementing this later.
Thanks for thinking all this through, David.
Thanks for testing this stuff :)
Re,
David
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
