Re: login-Passwort: Unicode vs. Latin1
* Nikolaus Schulz:
>> 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. Technisch unmöglich ist das sicherlich nicht, aber ich
>> sehe es als Zukunftsmusik.
>
> Was ist so schwierig daran, den String in ein generisches Format
> umzuwandeln? Sorry wenn das 'ne doofe Frage ist, ich arbeite mich grade in
> diese Sachen ein. Kann just nicht erkennen was das Problem dabei sein
> soll.
Es ist bestimmt nicht schwieriger, als andere Applikationen uft8-fit zu
machen. Nur muß sich halt einer hinsetzen und es tun. Und da sehe ich
dringendere Aufgaben: Mit fallen z.B. slrn (oder überhaupt slang), enscript
und dvi2tty ein, bei denen ich diese Fähigkeit schmerzlicher vermisse.
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. 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. Als Entwickler würde ich mich vor dem Öffnen des Editors erst
fragen, weshalb das jemand unbedingt machen will.
> Was mich doch irritiert, ist, daß ich bisher so ziemlich nirgends
> Hinweise auf diese ganze Problematik gefunden habe. Bin ich nur dran
> vorbeigestolpert? Wenn es so u.a. möglich ist, sich schnell und
> schmerzlos aus dem System auszusperren (auch als root!), dann verdient
> das m.E. einen warnenden Hinweis. Wo auch immer :-)
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. 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. Es müßte dazu wohl die init-Scripts
parsen, um es herauszubekommen. Da finde ich den Ansatz »bleib in Deiner
locale!!1!« pragmatischer.
> Der Auslöser für meine Versuche mit Locales ist übrigens Bug #220657
> (libxf86config schreibt lokalisierte XF86Config-4). Zu meiner
> Verwunderung finde ich auch nirgends etwas zur Codierung von
> Konfigurationsdateien. Offensichtlich werden die als ASCII-kompatibel
> vorausgesetzt, aber warum steht das nicht z.B. in der Debian Policy?
> Weil's so sonnenklar ist, oder wieso? Ich bin echt irritiert.
Sonnenklar ist, daß ohne encoding-Angabe für kein 8-Bit-Zeichen gesagt
werden kann, wie es denn auf einem System dargestellt werden soll, deshalb
ja Header in Mail und News und Meta-Angaben auf Webseiten. Für lokale
Plain-Text-Dateien ist es seit Jahr und Tag so, daß man für die
Übereinstimmung des Encodings des Textes mit dem seines Systems selbst zu
sorgen hat, zur Not mit recode(1). Die Meta-Angaben, welches Encoding ein
Text mit zunächst unleserlichen Ümläuten haben könnte, stammen da ja auch
entweder aus dem Wissen, auf was für einem System er erstellt wurde oder aus
gezieltem Raten. Textdateien haben nun einmal keine Header, ob es nun
Konfigurationsdateien sind oder nicht.
> 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.
> 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?
Grüße,
kro
--
Veteran of the Bermuda Triangle Expeditionary Force 1990-1951
(PGP/GPG 0xCE248A25)
Reply to: