[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: login-Passwort: Unicode vs. Latin1



Hi!

Andreas Kroschel wrote:
> >> Du müßtest also an dem Punkt ansetzen, wo Dein Klartext-Passwort
> >> verschlüsselt wird, d.h. den String vor dem Verschlüsseln generell in
> >> utf-8 umwandeln. 
[...]
> Es ist bestimmt nicht schwieriger, als andere Applikationen uft8-fit zu
> machen. Nur muß sich halt einer hinsetzen und es tun. 
[...]
> Warum ich die Notwendigkeit beim Thema Passwort nicht so sehe, ist
> sicherlich höchst subjektiv, aber vielleicht interessiert es dich ja
> trotzdem: Innerhalb derselben locale ist ja eh alles OK. Und wenn Du die
> locale zwischen Festlegung und Eingabe des Passwortes wechselst, ist die
> interne Zeichenrepräsentation ein IMHO sekundäres Problem: Primär weißt Du
> ja gar nicht, was Du da für Zeichen eingibst, da der Wechsel der locale i.a.
> auch einen Wechsel des Keyboard-Layouts bedeutet. Selbst mit einer internen
> utf-8-Ablage könntest Du nicht verhindern, daß man gar kein »ü« eingeben
> kann, wenn die locale gerade z.B. auf en_US steht. 

Das ist glaube ich nicht richtig. Das Tastaturlayout hängt AFAIK nicht
vom Locale des Benutzers, sondern von der Konfiguration des
Tastaturtreibers ab. Im Falle der Console ist dies die Kernel-Keymap
(loadkeys), im Falle von X ist dies i.W. XKB (bzw. xmodmap). 

> Die Arbeit, eine generelle Konvertierungsroutine in Passwortfestlegung
> und -eingabe einzubauen, würde also gerade einmal bewirken, zwischen
> unterschiedlichen Encodings derselben Sprache wechseln zu dürfen. Der
> Gewinn ist IMHO ziemlich gering. 

Hm.

> Bei passwd(1) kommen da Bytes an, woher auch immer. Woher soll das
> Programm wissen, daß Du eigentlich andere eingeben wolltest? Mit einer
> ungarischen Tastaturbelegung wäre es ja exakt das gleiche Problem. 

Es kommt doch nur darauf an, die Umwandlung "Keysymbol <--> codierter
Character" reversibel zu halten. Der Lümmel, der das Keysymbol bei
Eingabe erhält (passwd), könnte Sorge tragen, es locale-unabhängig zu
speichern. 

> OK, es könnte /etc/environment mit der aktuellen $LANG vergleichen und
> dann warnen.  Dann hättest Du aber ein entweder debian-only passwd(1)
> oder ein ziemlich bloatiges solches, das für zig Distributionen
> berücksichtigt, wo diese ihre system-locale abgelegt haben könnten. 

Das wäre die (schlechte) Alternative zur generischen Speicherung.
Anderes Thema.

> > So ganz begreife ich die Magik von Locales und das Zusammenspiel aller
> > beteiligten Komponenten --Tastaturtreiber, glibc, Locales, ggf. X11/XKB, was
> > vergessen?-- aber noch nicht. :-/
> > Gibts dazu einen netten Überblick? Die Betonung liegt auf "Zusammenspiel". 
> 
> Nix wissen das. Was ich hier so absondere, habe ich aus dem utf8-Howto.

Howto (welches?) oder das "UTF-8 FAQ for Unix/Linux"
<http://www.cl.cam.ac.uk/~mgk25/unicode.html>?

Was die Tastatur betrifft: für XKB gibt's den "Unreliable Guide to XKB"
<http://www.charvolant.org/~doug/xkb/html/xkb.html>, für die Console
/usr/share/doc/console-tools/lct.txt. Beides schon für sich genommen,
äh, verbesserungsfähig, aber das Gesamtbild...?

> > Der User guckt also in die Röhre? Zwangsläufig? Wenn das so ist:
> > kann man das irgendwo nachlesen?
> 
> Wenn ich unter Gnome hergehe und <Ctrl><Shift>1412 eingebe, habe ich als
> Passwort-Bestandteil das Silbenzeichen »WO« der kanadischen Indianer
> festgelegt. Jemand, der keine kanadische Indianertastatur besitzt und keine
> Möglickeit, das Zeichen anderweitig einzugeben, schaut in die Röhre, ja. Das
> ist mit einem »ü« prinzipiell nicht anders. Warum soll das extra irgendwo
> stehen?

Die Tastatur ist aber nicht das Problem, s.o. 


Nikolaus




Reply to: