Bug#379737: [Pkg-cryptsetup-devel] Bug#379737: cryptsetup: cannot handle UTF-8 in passphrase

[David Härdeman]

On Tue, Aug 22, 2006 at 02:54:46PM +0200, Robert Bihlmeyer wrote:
>David Härdeman <david at 2gen.com> 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