Hi, David Härdeman <[EMAIL PROTECTED]> writes:
>>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. Correct. But during normal use the user can set her console to non-UTF8. Cryptosetup could also use large translation tables (glibc's?) that may not be available in initramfs. People that encrypted CDRs with latin1-passphrases will see this problem (during normal use) for some time. >>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). The idea is to translate to UTF-8 on luksAddKey time. To be more concrete: 1. Old passwords that are not UTF-8 are "lost" and need to be manually fixed. Should be documented. 2. Newly created keys always get their passphrases translated from whatever encoding is active (as per LANG and LC_*) to UTF-8. 3. initramfs always sets the terminal into UTF-8 mode, so new passwords will work without a hitch. The feature from bullet 2 will probably need /usr/lib/gconv, but it is not needed for the version put onto initramfs. (That was my main fear, to bloat the initramfs by 5 megs or more.) For legacy compatibility (e.g. old CDRs) cryptsetup could take a --encoding=X parameter that translated from the current encoding (usually UTF-8) to X so that passphrases encoded in X are still usable. This leaves d-i to think about. -- Robbe
