On 28/08/2006 Robert Bihlmeyer wrote:
> >>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
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 an
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 hav
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 si
On Tue, July 25, 2006 11:49, Robert Bihlmeyer said:
> Maybe the console should be switched to Unicode mode akin to loading the
> right keymap?
Yes.
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
Package: cryptsetup
Version: 2:1.0.3-3
(Last report for today, I promise!)
This issue is related to the keymap troubles. If you luksAddKey in an UTF-8
environment entering "ä" in the passphrase will result in the two bytes 0xc3
and 0xa4. When you later reenter this "ä" during the initram/initrd p
6 matches
Mail list logo
