On Tue, Aug 22, 2006 at 02:54:46PM +0200, Robert Bihlmeyer wrote:
David Härdeman <[EMAIL PROTECTED]> writes:
I'll add some code later this week to the initramfs hook which checks for
a UTF-8 locale (the same code that the kbd package init.d script uses),
and if so, the initramfs script will have to run "kbd_mode -u" and
"loadkeys --unicode" instead of simply running loadkeys.
Makes sense.
There is a caveat: if someone has a latin1 locale, sets a passphrase with
non-ascii characters, and later changes to a utf8 locale, he is subsequently
locked out of his data.
Well, that goes for both cryptsetup during the initramfs stage and
during normal use of the system, so it's something that will have to be
addressed sooner or later by the user anyway.
(That will actually happen to me as I temporarily changed to a latin1 locale
to set my passphrase -- as a workaround to this bug. Once your fix hits my
machine this passphrase, containing non-UTF8 sequences, is unusable. Of course
I am forewarned, and can fix things...)
Yes, and it is kind of a corner case to have a UTF-8 system without a
UTF-8 password.
I wonder whether having non-ascii in my passphrase is worth it. It is more
"unstable" than one would think.
It will hopefully need no more changes after this fix :)
My other solution (normalising the passphrase to UTF-8 always) would have no
such problems, but it's a rather big hammer -- we can't put big translation
tables on initramfs I guess.
Well, it wouldn't work simply because we can't know which encoding to
convert from (i.e. was the old input in iso8859-1, or in iso8859-15, or
something else).
Regards,
David
