Aus dem Rechenzentrum

Heute war mal wieder so ein Tag… Eigentlich wollte ich mir nur einen Twitter-Client installieren, den man von der Kommandozeile aus nutzt: termtter. (Da ich einen Großteil meiner Arbeitzeit auf der Kommandozeile oder in emacs verbringe, hab ich eine gewisse Affinität dazu entwickelt und mache Dinge gerne auf der Kommandozeile. Auch ist der X-Server für mich bis heute ein starker Push-Faktor, doch lieber die Kommandozeile zu nutzen.)

Der Entwickler scheint Japaner zu sein oder zumindest Japanisch zu sprechen, deswegen muß man manchmal ein bißchen rumsuchen, bis man die Doku auch auf Englisch hat, aber das ist ja nicht weiter schlimm. Gleichzeitig bedeutet das aber auch, daß die Software wirklich keine Probleme mit Unicode macht, ein lobenswertes Qualitätsmerkmal. (Und daß ich dies heutzutage – immerhin im Jahr 2010 – noch loben muß, sollten sich alle die solches Lob nicht verdienen (Ihr wißt, wer Ihr seid) mal wieder zum Anlaß nehmen, sich in eine Ecke zu verkriechen und intensiv und sehr lange zu schämen!)

termtter ist in Ruby geschrieben und auch wenn ich deswegen heute mehr Aufwand gehabt habe, als mir lieb gewesen wäre, will ich das hier nicht als Nachteil werten. Die meiste Ruby-Software die mir bisher untergekommen ist, funktioniert sehr gut und ist häufig sogar halbwegs sicher (noch so ein Anlaß für andere, sich mal wieder zu schämen). Und im Gegensatz zu Python kann ich auch als jemand der Ruby nicht kennt, die Fehlermeldungen halbwegs interpretieren. Insgesamt gefällt mir Ruby und wenn ich will das in absehbarer Zeit mal lernen.

Nun aber zur Anleitung (die für Fedora 14 gilt):

Gleich als allererstes sollte man sich folgende Packete installieren, bevor man überhaupt an termtter denkt (ich gehe mal davon aus, daß grundlegende Build-Tools schon vorhanden sind):

sudo yum install rubygem-gem2rpm ruby-devel rpmdev-setuptree rubygem-json rubygem-highline rubygem-rspec rubygem-actionpack rubygem-curb rubygem-mocha rubygem-rack rubygem-typhoeus rubygem-eventmachine

Dann sollte man sich (falls noch nicht vorhanden) eine Build-Umgebung für RPM einrichten und dann die weiteren Abhängigkeiten von termtter die es bisher nicht als Packete für Fedora gibt in RPMs verwandeln. (Ich verwende für soetwas übrigens gerne einen speziellen User „builduser“, um mir nicht mein reguläres Heimverzeichnis zuzumüllen.) Um das zu bewerkstelligen gibt es das Tool gem2rpm, das mir heute fast durchgehend gute Dienste geleistet hat (s.u.).

Noch eine Randbemerkung: Ich verwende hier rpmdev-setuptree und das lohnt sich wirklich. Das schreibt einem nämlich auch schöne Dinge in die .rpmmacros-Config, etwa daß der Compiler auch gerne auf mehr als eine CPU zurückgreifen darf beim Build. Auf die Idee wäre ich selbst nie gekommen, daß man ihm das über ein RPM-Makro mitgeben kann.


rpmdev-setuptree
cd rpmbuild/SOURCES
gem fetch addressable
gem fetch em-http-request
gem fetch notify
gem fetch oauth
gem fetch rubytter
gem fetch termcolor
gem fetch termtter
gem2rpm addressable-2.2.2.gem > ../SPECS/rubygem-addressable.spec
gem2rpm notify-0.3.0.gem > ../SPECS/rubygem-notify.spec
gem2rpm oauth-0.4.4.gem > ../SPECS/rubygem-oauth.spec
gem2rpm rubytter-1.4.1.gem > ../SPECS/rubygem-rubytter.spec
gem2rpm termcolor-1.2.1.gem > ../SPECS/rubygem-termcolor.spec
gem2rpm termtter-1.9.0.gem > ../SPECS/rubygem-termtter.spec


So, und da war der Spaß aus. Wer aufgepaßt hat, dürfte bemerkt haben, daß ich hier kein Specfile für em-http-request erstellen lasse. Ich hab das hier bewußt ausgelassen, denn das Specfile das gem2rpm da erstellt ist schlichtweg unsinnig. em-http-request scheint kein gewöhnliches Gem zu sein, denn es benötigt als Build-Dependency ruby-devel und scheint irgendetwas zu kompilieren. Das Problem ist offenbar, daß gem2rpm nicht sonderlich viel Logik einsetzt um seinen Job zu machen, folglich nicht erkennt, daß es bei diesem Gem anders verfahren müßte und dann schließlich Schritte ins Specfile schreibt, die für diesen Fall ungeeignet sind. Der langen Rede kurzer Unsinn: Ich hab mir dann ein funktionierendes RPM für em-http-request einer anderen Linux-Distribution gesucht und mir von dem Specfile dort was abgeschaut und das was unter Fedora nicht ging gefixt. Vielen Dank an die Leute bei Mandriva Linux, insbesondere Rémy Clouard, hier ist das gefixte Specfile für em-http-request auf Fedora 14.

Nun kann man sich endlich ans Builden machen:


rpmbuild -ba ~/rpmbuild/SPECS/rubygem-addressable.spec
rpmbuild -ba ~/rpmbuild/SPECS/rubygem-notify.spec
rpmbuild -ba ~/rpmbuild/SPECS/rubygem-oauth.spec
rpmbuild -ba ~/rpmbuild/SPECS/rubygem-rubytter.spec
rpmbuild -ba ~/rpmbuild/SPECS/rubygem-termcolor.spec
rpmbuild -ba ~/rpmbuild/SPECS/rubygem-termtter.spec


Die so erzeugten RPMs kann man dann installieren:

sudo yum localinstall --nogpgcheck ~/rpmbuild/x86_64/rubygem-em-http-request-0.2.15-1.fc14.x86_64.rpm ~/rpmbuild/noarch/rubygem-notify-0.3.0-1.fc14.noarch.rpm ~/rpmbuild/noarch/rubygem-rubytter-1.4.1-1.fc14.noarch.rpm ~/rpmbuild/noarch/rubygem-termtter-1.9.0-1.fc14.noarch.rpm ~/rpmbuild/noarch/rubygem-addressable-2.2.2-1.fc14.noarch.rpm ~/rpmbuild/noarch/rubygem-oauth-0.4.4-1.fc14.noarch.rpm ~/rpmbuild/noarch/rubygem-termcolor-1.2.1-1.fc14.noarch.rpm

termtter benötigt eine kleine, aber feine Config, die man sich unter .termtter/config ablegen sollte:


config.user_name = 'your id'
config.password = 'your password'
config.update_interval = 60

#Termtter::Client.init do |t|
# t.plug 'growl'
#end


Beim ersten Start wird termtter OAuth triggern und im Browser eine URL öffnen die zu Twitter führt. Dort muß man sich nochmal einloggen und erhält dann eine PIN, die man bei termtter eingibt. Danach ist termtter bei Twitter authentifiziert und kann benutzt werden. Eine Manpage fehlt leider bisher (wenn jemand weiß, wie man die Ruby-Doku in eine Manpage umwandeln kann: ich freue mich über Input), aber termtter hat eine eingebaute Hilfe, einfach „help“ eingeben und lesen. Diese Hilfe ist übrigens erschöpfend, d.h. das was da steht ist auch schon alles, was man über termtter wissen muß. Twitter ist ja nicht so komplex.

Wer blickt denn bitte bei create mask, create mode, force create mode, force directory mode, force directory security mode, force security mode, directory mask, directory mode, directory security mask und security mask noch durch?

Wenn man die bestehende Samba-Doku dazu einfach mal wegschmeißt und frisch an die Sache herangeht, ist das System eigentlich sehr leicht nachvollziehen und folgt einer gewissen inneren Logik.

Zunächst: Keine der Anweisungen erzwingt für sich bestimmte Rechte. Nein, auch nicht die mit force im Namen (was ich früher in meiner Unkenntnis immer dachte).

Stattdessen geben die entsprechenden Konfigurationen ein Minimum und ein Maximum für die Rechte vor. Die Maximum-Angaben verhindern, dass ein Client zuviele Rechte vergibt (z.B. Ausführungsrechte, wenn die von ihm angelegten Dateien nie ausgeführt werden sollen); die Minimum-Angaben setzen Rechte, auf die nicht verzichtet werden soll (z.B. Gruppenschreibrechte in einer gemeinsam genutzten Freigabe, auch wenn der Client die gar nicht setzen wollte).

Minimum und Maximum funktionieren durch eine bitweise Verknüpfung mit AND und OR. Die endgültigen zum Einsatz kommenden Rechte werden wie folgt berechnet:

• Rechte, die der Client gerne setzen möchte
• AND Bitmaske, um das Maximum zu erzwingen (unerwünschte Rechte wegschneiden)
• OR Bitmaske, um das Minimum zu erzwingen (erzwungene Rechte setzen)
• ergibt endgültige Rechte

AND entfernt alle Bits, die in der Client-Vorgabe gesetzt wurden, aber nicht in der Maske stehen, d.h. es werden Rechte weggenommen, die der Client sich zuviel nehmen wollte. Beispiele:

• 777 AND 750 => 750 (Die erste 7 ist okay, die zweite wird auf 5 gekürzt, die dritte wird auf 0 gekürzt.)
• 000 AND 750 => 000 (Alle drei Nullen liegen bereits innerhalb des Maximums.)

OR setzt alle Bits, die in der Client-Vorgabe nicht gesetzt wurden, aber in der Maske stehen, d.h. es werden Rechte erzwungen, die der Client gar nicht gesetzt hat. Beispiele:

• 000 OR 750 => 750 (Sowohl bei der ersten als auch bei der zweiten Null wurde das Minimum unterschritten.)
• 777 OR 750 => 777 (Alle drei Siebenen erreichen oder übertreffen bereits das Minimum.)

Durch Kombination (und zwar nur durch Kombination!) der beiden lassen sich damit faktisch ganz bestimmte Rechte erzwingen, nämlich in dem Minimum und Maximum auf den gleichen Wert gesetzt werden. Hier mal einige Beispiele mit 750 als Minimum (erster Schritt) und als Maximum (zweiter Schritt):

• 000 AND 750 => 000 … 000 OR 750 => 750
• 777 AND 750 => 750 … 750 OR 750 => 750
• 700 AND 750 => 700 … 700 OR 750 => 750
• 070 AND 750 => 050 … 050 OR 750 => 750

Weil’s so schön ist, wird auch noch unterschieden zwischen der Rechtevergabe beim Anlegen und der nachträglichen Rechteveränderung über die entsprechende Dialogbox des Windows-Clients.

Nun wird’s also Zeit für die entscheidenden …

Faustregeln

1. create mode und directory mode sind verwirrende und vor allem inkonsistente Alias-Bezeichnungen, die ignoriert werden sollten. Weg damit!
2. Alles, was security im Namen hat, bezieht sich auf die nachträgliche Änderung von Rechten; alles andere auf die Rechte beim Anlegen.
3. Alles, was directory im Namen hat, bezieht sich auf Verzeichnisse; alles andere auf Dateien.
4. Ein Statement ist entweder ... mask oder force ... mode. Alles mit ... mask funktioniert dabei als AND, schneidet also überzählige Bits weg. Merke: A wie in „mask“ = A wie in „AND“. Alles mit force ... mode funktioniert dabei als OR, setzt also nicht angegebene Bits dazu. Merke: O wie in „force“ und „mode“ = O wie in „OR“.

Aus Regel 2, 3 und 4 ergeben sich damit alle möglichen 2 ^ 3 = 8 Kombinationen: Aktion (Anlegen/Ändern), Objekt (Datei/Verzeichnis), Methode (Minimum/Maximum).

Und wer sich gerne eine kleine Kurzübersicht der möglichen Kombinationen an den Monitor tackern will, nimmt diese hier:

Kurzübersicht

Rechtevergabe beim Anlegen erzwingen:

• Dateien:
• [max] create mask
• [min] force create mode
• Verzeichnisse:
• [max] directory mask
• [min] force directory mode

Rechtevergabe beim Ändern erzwingen:

• Dateien:
• [max] security mask
• [min] force security mode
• Verzeichnisse:
• [max] directory security mask
• [min] force directory security mode

Tip: Üblicherweise möchte man ja nicht, dass einmal beim Anlegen gesetzte Rechte nachträglich verändert werden – dann hätte man sich das Erzwingen der Rechte beim Anlegen ja auch gleich sparen können. Insofern sollte eine Nicht-„security“-Einstellung immer durch die entsprechende „security“-Einstellung ergänzt werden.

Fazit:

Will man nur ein Maximum an Rechten erzwingen (= bestimmte Rechte verbieten, obwohl der Client sie setzen wollte), braucht man diese vier Einstellungen (wir erinnern uns: Maximum wird durch AND erzielt, AND mit A, so wie in „mask“):

create mask
directory mask
security mask
directory security mask

Will man nur ein Minimum an Rechten erzwingen (= bestimmte Rechte immer setzen, auch wenn der Client das gar nicht wollte), braucht man jene vier Einstellungen (wir erinnern uns: Minimum wird durch OR erzielt, OR mit O, so wie in „force“ und in „mode“):

force create mode
force directory mode
force security mode
force directory security mode

Will man ganz bestimmte Rechte erzwingen, unabhängig davon, was der Client sich für Rechte wünscht, braucht man alle acht Einstellungen:

create mask
force create mode
directory mask
force directory mode
security mask
force security mode
directory security mask
force directory security mode

Der CDU-Politiker Axel Fischer wird wohl nicht geahnt haben, was er da lostritt, als er vor ein paar Tagen ein „Vermummungsverbot im Internet“ forderte. Neben dem üblichen Für und Wider aus der netzpolitischen Welt schwappte nämlich ob der Absurdität dieser Forderung schnell eine Welle des Spotts durch das Internet. Die Phrase „Axel E. Fischer, CDU, fordert…“, gefolgt von absurden Begriffsverknüpfungen, wurde zum Meme und erfreute sich für ein paar Tage großer Beliebtheit, ähnlich wie vor ein paar Jahren „Schönbohm fordert…“, nur daß es damals noch kein Twitter gab und das Meme deutlich weniger populär wurde. Meine drei persönlichen Favoriten seien hier nicht verschwiegen: „Axel E. Fischer, CDU, fordert Führerscheinpflicht für Rickroller.“, „Axel E. Fischer, CDU, fordert Frauenquoten für Man-in-the-Middle-Angriffe.“ und „Axel E. Fischer, CDU, fordert Fangquoten für Fail-Whales.“

Mittlerweile hat Axel Fischer seine Äußerungen relativiert. Es gehe ihm gar nicht um das ganze Internet, sondern nur um „Foren mit politischen Abstimmungsmöglichkeiten“.

Ich persönlich fragte mich ja kurz, ob er da auf Liquid Feedback anspielen will, aber dann ist auch schon die Logik-Einheit in meinem Gehirn angesprungen und hat „der ist in der CDU, nicht der Piratenpartei“ dazwischen gerufen.

Eigentlich könnte einem das ja leid tun. Der Mann fühlt sich offenbar mißverstanden und ungerechtfertig mit Häme überschüttet. Aber niemand zwingt ihn sich mit Netzpolitik zu befassen, der äußert sich da freiwillig, also muß er auch damit leben können, wenn er nach derart unsinnigen Aussagen von netzaffinen Menschen erst wie ein Marsmensch angestarrt und dann ausgelacht wird. Wenn ich beim Bauernverband reinspaziere und fordere, daß es auch fettreduziertes Melkfett für figurbewußte Kühe geben muß, dann würde es mir kaum anders ergehen.

Ich hab mich auch ein bißchen darüber amüsiert und versucht ein paar Variationen des Memes zu bilden. Ich glaube, die ganz großen Würfe sind hier anderen gelungen, aber was soll’s:

• Axel E. Fischer, CDU, fordert totales Routen-Verbot an deutschen Schulen.
• Axel E. Fischer, CDU, fordert Apothekenpflicht auch für SQL-Injektionen.
• Axel E. Fischer, CDU, fordert Bio-Siegel für iMacs aus Freilandhaltung.
• Axel E. Fischer, CDU fordert schärfere Salmonellenkontrollen bei iMacs.
• Axel E. Fischer, CDU fordert niedrigere Schallschutzgrenzwerte für Pings.
• Axel E. Fischer, CDU fordert Gesichtsverpixelungsgebot in IMAP-Diensten.
• Axel E. Fischer, CDU, fordert Kopfpauschale für Festplatten.
• Axel E. Fischer, CDU fordert elektronisches Entgeltnachweisverfahren (ELENA) für alle Arbiter.

Auf den letzten bin ich besonders stolz. :-)

Etwas tiefsinniger war dann noch: „Axel E. Fischer, CDU, fordert Casinolizenzen für Apachen.“ — Dazu muß man wissen, daß in vielen Bundestaaten der USA de facto ausschließlich Nachfahren von Ureinwohnern Casinolizenzen erhalten, und zwar nur für den Betrieb von Casinos auf ihrem eigenen Land. Das geht soweit ich das verstehe auf alte Gerichtsurteile (in den USA und England werden Rechtsnormen ja nicht nur vom Parlament, sondern auch per Gerichtsurteil geschaffen) zurück, die den Nachfahren der Ureinwohner begrenze Autonomie auf ihren verbliebenen Flecken Land gewährt. Das ganze wurde dann wohl von der Reagan-Regierung mal mit einem Gesetz weiter reguliert.

Mein Problem mit diesem Meme war insgesamt eher, daß viele Varianten davon für mich zu nah an der Realität dran waren und mir so das Lachen im Halse stecken blieb. So zum Beispiel bei „Axel E. Fischer, CDU, fordert Nacktscanner für Datenreisende.“ — ehrlich gesagt hab ich die Vorratsdatenspeicherung ziemlich genau so empfunden. Ganz ähnlich ging es mir bei „Axel E. Fischer, CDU, fordert Öffnungszeiten für Online-Shops.“ — auch das droht uns bereits, das Stichwort hier lautet Jugendmedienschutzstaatsvertrag. In Deutschland gehostete (Achtung, ironischer Euphemismus:) Erwachsenenunterhaltungsangebote sollten zumindest einem Entwurf nach dann nämlich nur nachts geöffnet sein — ich hoffe der Entwurf wurde nochmal geändert. Jeder netzaffine Mensch faßt sich bei dem Gedanken an den Kopf und schaut aufs Kalenderblatt in der Hoffnung, es wäre vielleicht doch irgendwie der 1. April, verzweifelt aber letztlich bei dem Gedanken, daß es viele Menschen in unserer Gesellschaft gibt, die sich bei dem Gedanken eben gerade nicht an den Kopf fassen und allzu oft leider auch nicht belehrbar sind. Ganz ähnlich geht es mir immer, wenn ich mit Leuten konfrontiert werde, die ernsthaft glauben Homosexualität könnte ansteckend sein oder Homosexuelle würden versuchen Leute zu rekrutieren oder zu bekehren. Schließlich kommt man sich ja auch selbst ein bißchen seltsam vor, wenn man sich als der einzige in seinem Umfeld sieht den das befremdet.

Man konnte anhand dieses Memes sehr deutlich sehen, wie groß die Kluft in unserer Gesellschaft zwischen denen die das Internet in seiner ganzen Vielfalt schätzen und mindestens ein bißchen verstehen, und jenen die ihm mit völligem Unverständnis und weitgehender Ahnungslosigkeit gegenüber stehen selbst wenn sie es nutzen sollten, tatsächlich ist. Dieser Konflikt zwischen den modernen Ludditen und den selbstproklamierten Netzbürgern ist so grundlegend, daß man kaum Vergleiche dafür finden kann, so etwas ist nunmal noch nicht vorgekommen. Würden hierzulande Amische die Politik in Fragen der Wissenschaft, Unterhaltungskultur und der sexuellen Freizügigkeit prägen, wäre ein ähnlicher Konflikt denkbar. Meines Erachtens wäre es aber äußerst unfair den Amischen so viel Überheblichkeit zu unterstellen das auch nur zu versuchen, denn in der Tat halten sie sich aus den Angelegenheit der Welt jenseits ihrer Gemeinden nunmal aus Überzeugung heraus.

Je länger dieser Konflikt nun schon andauert, desto größer scheint die Kluft zu werden. Selbst nach der Bildung der Enquete-Kommission Internet und digitale Gesellschaft scheint die Kluft immer noch weiter aufzureißen. Entwickelt sich der Teil der Gesellschaft, der das Netz halbwegs kennt und sich gerne dort rumtreibt zu schnell und kommen jene, die mit all dem nicht viel anfangen können einfach nicht hinterher, werden sie wohlmöglich zunehmend abgehängt? Werden wir in ein paar Jahren von digitalen Verlieren sprechen? Werden Abgehängte und Netzverweigerer in ein paar Jahren durch die Vorstädte marodieren?

Spaß (hoffentlich wird das nicht wahr!) beiseite. Ich will hier auch ein bißchen was aus unserer täglichen, beruflichen Erfahrung einfließen lassen. Wer hier regelmäßig mitliest, kennt das zum Teil schon: Es vergeht fast keine Woche, in der uns nicht irgendein politisches Vorhaben Sorgen bereitet, weil es alle möglichen negativen Auswirkungen auf unsere Arbeit, also unsere Jobs, haben kann: Wären wir von der Vorratsdatenspeicherung betroffen gewesen, hätte uns das viel Geld kosten können, meinen Arbeitsplatz würde es dann vermutlich gar nicht geben. Haben wir Kunden, die beim Zwang nächtlicher Öffnungszeiten für Erwachsenenangebote mit dem Hosting ins Ausland abwandern könnten? Sind wir als unfreiwillige Mitstörer haftbar, wenn unsere Kunden ihre Kunden betrügen?

Und wenn es keine politischen Vorhaben sind, dann sind es Winkeladvokaten die einer Heuschreckenplage gleich das Land mit Abmahnungen überziehen, weil sie eine neue Gesetzesfehlformulierung entdeckt haben, die sie ausbeuten können. „Computer verarbeiten IP-Adressen! Rette sich wer kann!“ Und wenn es nicht das ist, dann sind es Ermittlungsbehörden. Kein Jahr geht ins Land, ohne daß seltsame Schreiben und Anrufe von Polizisten und Staatsanwälten bei uns eingehen, bei denen wir nicht erstmal die Zusammenhänge entwirren und dann Aufklärungsarbeit zu leisten haben. Immerhin nehmen die meisten Polizisten und Staatsanwälte das sehr dankbar an, aber es gibt leider auch immer wieder renitente Fälle, die uns dann letztlich viel Sorgen bereiten und natürlich auch (Anwalts-)Kosten verursachen. Da ist man dann schon bald froh, wenn es wenigstens mal zur Klageerhebung kommt, denn nur wenn das passiert und man den Prozess gewinnt, kann man die Kosten erstattet bekommen.

Angesichts dieser Erfahrungen, aber vor allem der Geschichten die so durch die Medien gehen kommt mir mittlerweile der Verdacht, daß es auch einen guten Anteil von Menschen in unserm Land gibt, die hier nicht lernwillig sind, sondern einfach die Uhren zurückgedreht haben wollen und zwar um mehr als eine Stunde. Ich könnte jetzt das böse Wort Integrationsverweigerer dafür benutzen, aber da ich bis heute keinen die Integration verweigernden Einwanderer kennen gelernt habe, sondern nur solche die einfach nicht die richtigen Angebote gefunden haben oder die richtigen Angebote nicht sie, ist der Begriff Integrationsverweigerung für mich verbrannt. Ich bleibe lieber bei Ludditen, das ist auch nicht politisch korrekt, aber ich kenne keine echten Ludditen denen es schadet.

Im Fragen des Internets kommt es mir jedenfalls oft so vor, als wenn da die Kluft größer wird und das auch mehr und mehr zu Verwerfungen führt. Es wird auf absehbare Zeit eine der wichtigsten Aufgaben unserer Gesellschaft sein, diesen Konflikt noch weiter auszuhalten und am Prozess einer Lösung zu arbeiten. Immerhin scheint zumindest die Notwendigkeit des Diskurses endlich eingesehen worden zu sein. Jetzt müssen wir wohl als nächstes erstmal die Diskussionpartner der anderen Seite soweit bilden, daß der Diskurs ernsthaft geführt werden kann. Solange die nämlich noch auf dem Feld „Oh Gott, in Foren und auf Mailinglisten posten die Leute pseudonym! Die verwenden keine Klarnamen? Hilfe!“ stehen, kann es nämlich keinen sinnvollen Diskurs geben, dafür müßte man schon die gleiche Sprache sprechen.

Insofern ist es vielleicht gar nicht so schlecht, wenn Apple an seinem walled garden pflanzt und mit Facebook und anderen Diensten wieder AOL-ähnliche walled communities im Internet entstehen. Möglicherweise können die als die geschützen Kinderspielwiesen dienen, die hier nötig zu sein scheinen.

Insofern hoffe ich auf bessere Zeiten, drücke aber gleichzeitig meine Befürchtungen in folgender Variante des beliebten Memes aus: „Axel E. Fischer, CDU, fordert Bombardierung von Rechenzentren durch die Bundeswehr bei akuter Terrorgefahr.“ Das passt auch gut zu den aktuellen Fnords in den Nachrichten.

Wenn ich eine Software schreibe, die eine E-Mail konstruiert – Header, Body, das Ganze in einer adäquaten Kodierung – dann habe ich verschiedene Möglichkeiten, um zu prüfen, ob ich alles richtig gemacht habe. Ich kann möglichst viele verschiedene Varianten samt jeglicher hypothetischer Sonderfälle raus in die Weltgeschichte schicken und schauen, ob alle damit klarkommen: Ob die Mail von Mailservern wie Sendmail, qmail, Postfix, Courier, Exchange, Exim oder Lotus Domino problemlos durchgeleitet werden kann (und viele davon laufen nicht nur unter einem Betriebssystem, sondern unter vielen verschiedenen, wenigstens unter verschiedenen Versionen des gleichen Betriebssystems), und ob hinterher Outlook, Outlook Express, Thunderbird, Eudora, Evolution, Mail.app, Lotus Notes, Sylpheed, Balsa, verschiedene Webmailer und Smartphone-Clients meine Mail korrekt anzeigen.

Oder ich halte mich einfach an den Standard, wie eine Mail auszusehen hat: RFC 822.

Die heutige kleine Geschichte dreht sich um einen Doppelpunkt; genauer gesagt, um zwei. Ein User auf einem unserer Server arbeitet für einen Verein, dessen Corporate Identity einen doppelten Doppelpunkt im Schriftzug des Vereins vorsieht, im Sinne von mein::verein. Als Klartextname für E-Mails ist entsprechend vorgesehen: Vorname Nachname | mein::verein. Darüber kann man streiten, aber fest steht: Es ist natürlich völlig legitim, im Klartextnamen auch Sonderzeichen verwenden.

Das Problem entzündet sich nun daran, dass jener User als Mailclient Thunderbird einsetzt, und Thunderbird erstellt aus dem Klartextnamen und der E-Mail-Adresse folgenden Absender:

From: Vorname Nachname | mein::verein <vorname.nachname@mein-verein.de>

Um’s direkt vorwegzunehmen: So ist es falsch. Richtig wäre vielmehr:

From: "Vorname Nachname | mein::verein" <vorname.nachname@mein-verein.de>

Der Grund dafür liegt darin, dass der Doppelpunkt zur Zeichenklasse der „specials“ gehört, was schon von daher nicht verwunderlich ist, als dass er bereits das Trennzeichen zwischen der Headerbezeichnung („From“) und dem Inhalt des Headers ist. RFC 822 formuliert sogar ausdrücklich aus:

     specials    =  "(" / ")" / "<" / ">" / "@"  ; Must be in quoted-
                 /  "," / ";" / ":" / "\" / <">  ;  string, to use
                 /  "." / "[" / "]"              ;  within a word.

Keine große Sache, möchte man meinen. Trivial geradezu. Aber Thunderbird macht’s eben nicht.

Problematisch wird das nun, wenn die Mail an ein Programm gelangt, das sich an den Standard hält und dann entsprechend nicht weiß, wie es mit dieser Zeile umgehen soll. Das ist vielleicht nicht ganz einfach zu verstehen, denn als Mensch schaut man auf die Zeile drauf und sieht natürlich, wie sie gemeint ist. Software ist aber kein Mensch, sondern arbeitet nach strikten Abläufen, und diese Abläufe orientieren sich im Fall von Software, die Mails verarbeiten muss, logischerweise daran, wie die Regeln laut RFC den Aufbau vorschreiben. Im konkreten Fall ist es qmail-inject, das – weil der Empfänger seine Adresse als Weiterleitung konfiguriert hat – die Mail verarbeiten muss, um sie wieder der Queue des Mailservers zuzuführen, und das endet dann mit einer Bouncemail, die uns sagt:

qmail-inject: fatal: unable to parse this line:
From: Vorname Nachname | mein::verein <vorname.nachname@mein-verein.de>

Dass der Header falsch war, war auf den ersten Blick ersichtlich. Die wichtige Frage ist aber: Warum? Hat der Absender da etwas falsch gemacht – oder gar Thunderbird?

Es stellt sich heraus: Es gibt bereits eine ganze Reihe von Bug-Reports für Thunderbird dazu. Um nur einige zu nennen:

• 524471 – Address from is incorrectly quoted in To: header field
• 273037 – RFC 822 ’specials‘ not being properly quoted as per spec
• 317296 – Recipient headers can be invalid if there are invalid chars that aren’t quoted
• 474136 – from header line – no quoting if required by a colon within display name

(Der Fehler betrifft neben dem „From:“-Header genauso auch den „To:“-Header, insofern sind die entsprechenden Bug-Reports zu letzterem ebenfalls als zu unserem Problem passend anzusehen.)

Besonderes Augenmerk wäre hier auf den zweiten zu legen, in dem ansatzweise eine Diskussion dazu stattfand, während in den anderen überhaupt nichts Signifikantes passiert ist. Im fraglichen Ticket beklagt sich ein Anwender, bei der Verarbeitung der Mail auf Empfängerseite mittels javamail würde die Zielanwendung crashen. Nun ist das ohne Frage unschön und sollte nicht „so“ passieren, aber immerhin haben wir hier auch zwar nicht mit einem Crash zu tun, aber doch immerhin mit einem sauberen Abbruch, der ordentlich ausgibt, warum der Mailheader nicht verarbeitet werden konnte. Ob nun Crash oder sauberer Abbruch: Für den Enduser ist das nicht relevant. Die Mail wird nicht weitergeleitet. Das ist schlecht.

Einer der Thunderbird-Entwickler stellt nun zunächst ganz sachlich fest:

I assume he’s speaking about RFC 822, which states merely that : is a special, and „must“ be quoted if not being used as a delimiter. We may be not adhering to this spec.

Einsicht ist der erste Schritt zur Besserung, möchte man meinen. Doch weit gefehlt:

I receive mails daily where the colon is not quoted, and Mozilla doesn’t crash. Nor did Eudora, Outlook or Outlook Express, Pine, nor any other mail client I’ve used. It should be able to gracefully handle errors, and somethign as simple as a colon in the TO: field line should not crash it.

Das sind so die Momente, wo ich froh bin, nur vor einem Monitor zu sitzen, um nicht einem realen Menschen meine akute Sprachlosigkeit demonstrieren zu müssen. „Andere Mailclients haben da auch kein Problem mit“ ist nun wirklich überhaupt kein Grund, eine Missachtung von Standards zu rechtfertigen. Wenn ich selbst einen Mailclient schreiben wollte, dann interessiere ich mich nicht die Bohne dafür, welcher Mailclient in welchen Aspekten irgendwie rummurkst: Entweder er macht es richtig, oder er macht es falsch. Thunderbird macht es falsch, und es ist nicht meine Aufgabe, in meiner Software Workarounds für Bugs in Thunderbird zu schreiben.

Nun ist es natürlich völlig legitim, zu sagen: Naja gut, javamail sollte nun aber nicht gleich crashen. Ist ja auch richtig. „Be liberal in what you accept“ und so. Aber davon unabhängig kann man ja trotzdem auch schon mal den Fehler auf der eigenen Seite beheben, gerade nachdem man schon eingesehen hat, dass es einen gibt. Aber, Überraschung:

In fact, no character there should crash the app. In fact, the app should never crash due to malformed mails. That’s just bad form. […] Good luck to the javamail guys in fixing their crasher.

Mit anderen Worten: Ist mir egal. Die Gegenseite soll sich nicht so anstellen. Viel Glück.

Ich glaube, was mich an dieser Sache so bestürzt, ist, dass ich diese Geisteshaltung ausgerechnet bei einem Open-Source-Projekt erlebe. Schließlich ist freie Software ideell eng mit offenen Standards und darauf basierend mit einem starken Bestreben nach Interoperabilität verbunden. Man stelle sich vor, im Bereich der Entwickler von Browsern einerseits und Webservern andererseits gäbe es ähnliches Gezetere, weil man sich eben nur so vage und nicht ganz genau an den HTTP-Standard hielte, mit der Folge, dass ein Internet Explorer nur noch mit einem IIS so richtig kommunizieren könnte und ein Firefox nur noch mit einem Apache. Das wäre natürlich total lächerlich und würde die Entwicklung des Webs um Jahre zurückwerfen.

Vielleicht sehe ich die Sache auch deshalb so eng, weil ich seit Beginn meines Arbeitslebens eng mit der Software von Dan Bernstein verbunden bin, der unter anderem auch den qmail-Mailserver entwickelt hat, dessen Komponente qmail-inject sich gerade an dem fehlerhaften Header stört. Bernstein gehört zu den Leuten, die geradezu eine innige Liebe zu Standards und Interoperabilität entwickelt haben – und vor allem eine um so innigere Abneigung gegenüber Produkten und Personen, die diese Liebe nicht teilen. Auf den Mailinglisten weht ein rauer Wind, und nicht wenige haben über die Jahre hinweg geradezu eine „Nee, wenn das Programm von Bernstein ist, dann benutze ich das nicht, der Typ ist ein A***“-Haltung kultiviert. Letztlich ist das aber genau so ein Personenkult (nur eben ein negativer), wie Bernstein ihn stets abgelehnt hat: Für ihn war und ist wichtig, dass Software korrekt und berechenbar funktioniert, unabhängig davon, ob dahinter ein netter Mensch steht oder ein A***. Für diese Haltung hege ich große Sympathie.

Doch kurz zurück zum Bug-Report. Dessen bizarrster Punkt ist nämlich noch gar nicht gekommen. Der kommt erst jetzt, in der kurzen Code-Analyse eines anderen Community-Mitglieds:

According to nsMsgHeaderParser.cpp we’re not quoting :s so as not to break some systems which aren’t expecting them to be quoted…

Also, nur um das nochmal festzuhalten: Quoting spezieller Zeichen ist eine ausdrückliche Vorgabe von RFC 822. Und weil es nun „einige Systeme“ gibt, die mit einem solchen Quoting nicht umgehen können, sich also nicht an den Standard halten … spart Thunderbird sich das Quoting einfach und hält sich so ebenfalls nicht mehr an den Standard – und empfiehlt dann denen, die sich an den Standard halten und sich somit legitimerweise an dem fehlerhaften Header stören, doch gefälligst mal Fünfe gerade sein zu lassen. Bizarr finde ich das vor allem deshalb, weil alle anderen mir bekannten Mailclients (um mich mal kurz auf das argumentative Niveau des Bug-Reports herabzulassen) in Tests den Klartextnamen mit den Doppelpunkten korrekt in Anführungszeichen setzen, sogar Outlook und Outlook Express, die in Sachen Standardkonformität sich nun wirklich über Jahre hinweg einen außerordentlich schlechten Ruf erarbeitet haben.

Insbesondere die Arroganz, mit der hier die Veranwortung für den eigenen Fehler auf Dritte geschoben wird, hat mich bei der Lektüre wirklich erstaunt. „Be liberal in what you accept“ sollte aus meiner Sicht ein Ansatz sein, um die Interoperabilität zwischen Applikationen zu erhöhen – nicht aber eine Rechtfertigung dafür, selbst fehlerhafte Daten generieren zu dürfen: „Be conservative in what you send“ ist schließlich ebenfalls eine Vorgabe des gleichen Robustheitsprinzips. Übrigens die, die zuerst genannt wird. Und ich finde, von anderen zu verlangen, ihre Hausaufgaben zu machen, steht in erster Linie denen zu, die ihre eigenen bereits gemacht haben. Das sieht unser Thunderbird-Entwickler aber nicht so und polemisiert:

I think clients these days are generally smart enough to know what’s a header and what isn’t (usually).

Na und? Vielleicht stehe ich mit dieser Ansicht zunehmend alleine da. Aber ich finde wichtig, dass Software berechenbar ist und nicht „smart“. Dass sie Fehler in Daten als Fehler in Daten benennt und diese sauber und ordentlich ablehnt. Zu verlangen, dass eine Software Daten als fehlerhaft erkennt, daraus eigene Schlüsse zu ziehen versucht und dann statt dem, wozu man sie beauftragt hat, das macht, was sie für vermeintlich richtig hält, würde ich als Ursache vieler Übel betrachten.

Demjenigen, der den Fehler überhaupt erst an die Thunderbird-Entwickler gemeldet hat, gebührt das Schlusswort des Bug-Reports, und er offenbart dabei von allen Beteiligten die größte Weisheit:

I agree it is dumb to not have the client gracefully handle this. Yet if it is part of a standard, it makes sense. Otherwise standards become pointless; not all reasons for a given standard are always obvious up front, even when we know most of the reasons.

Und das ist genau der Punkt: Kaum eine einzelne Person kann die Vielzahl von Gründen dafür ermessen, warum sich ein Standard so und nicht anders entwickelt hat. Vor allem kann kaum eine einzelne Person die Folgen einer Abweichung vom Standard einschätzen – hier versäumt man zwei Anführungszeichen; da crasht deswegen ein Mailclient, und dort funktioniert eine Weiterleitung nicht mehr. Die Entwickler wären gut beraten, ein wenig Demut walten zu lassen und sich zu sagen: Im Zweifelsfall wissen wir zwar nicht, warum der Standard das so vorschreibt. Vielleicht finden wir es auch dumm, wie es der Standard will. Aber: Dutzende von Mailservern auf Dutzenden von Betriebssystemen sowie hunderte von Mailclients verlassen sich darauf, dass alle es so machen, wie der Standard es verlangt – also sollten wir uns lieber auch daran halten.

Lassen wir zum Schluss noch einmal Bernstein zu Wort kommen, der sich bereits vor über einem Jahrzehnt reichlich desillusioniert zum Thema Protokolldesign äußerte:

So you want to design a protocol? I’ll let you in on an evil secret: most implementors will never read your spec.
Instead, they’ll look at some common examples and write the most obvious code that works for those examples.

Thunderbird hat mir heute ein weiteres frustrierendes Beispiel für diese Geisteshaltung geliefert. Der letzte Eintrag des Tickets ist übrigens aus dem Dezember 2004. Jüngere Tickets, die das Problem ebenfalls beschreiben, blieben bisher unbearbeitet. Für mich entspricht das einem unausgesprochenen WONTFIX.

Während die Finanzkrise ihr Hoch zu vermelden hatte und tagtäglich in den Zeitungen nichts anderes mehr zu lesen war, habe ich nichts, aber auch gar nichts davon gespürt. Keine schlechtere Zahlungsmoral, kein Auftragsrückgang. Irgendwie wirkt es, als würde diese Welle erst jetzt hereinschwappen.

Ende September, erster Kunde:

habe heute X.XXX,XX Euro überwiesen, die X.XXX,XX Euro kommen so schnell wie möglich

Mitte Oktober, zweiter Kunde:

Naja….: der Stand der Dinge: ich habe zwei ganz gute Eisen im Feuer, die wieder für Stabilität sorgen werden. Es sollte gegen Mitte November sein, so dass ich dir das Geld in Raten ab November wiede rzahlen könnte.

Ende Oktober, dritter Kunde:

Aber ich habe mehrere ausstehende Rechnungen – das sollte in zwei Wochen eingehen – und gleichzeitig mein Hauptprojekt $FIRMA hat seit Mai nicht mehr bezahlt. Ich schätze nächste Woche kann ich überweisen, da sollte wenigstens einer der Kandidaten gezahlt haben ….

Ende Oktober, nochmal erster Kunde:

die Rechnung über XXX,XX Euro werde ich diese Woche noch zahlen. Die 2. Anfang nächsten Monats, wenn die Kunden endlich gezahlt haben, das ist im Moment etwas schwierig.

Anfang November, vierter Kunde:

muss mich erst mal bei dir ganz arg entschuldigen. Hatte dir ja zugesagt, dass ich die Hosting-Rechnung zeitnah bezahle, kurz zuvor hatte ich ja meinen Quartalslauf. Warum auch immer, so einen miesen Zahlungseingangs-Verlauf habe ich ehrlich gesagt noch nicht erlebt, bin es normalerweise eigentlich gewohnt, dass rund 75% der Rechnungen innerhalb von drei Wochen bezahlt werden. Diesmal lassen sich die Leute mehr als genug Zeit.

Es wäre vielleicht nicht so schlimm, wenn’s nicht in fast jedem einzelnen Fall um vierstellige Summen gehen würde. Und wenn nicht noch die Kunden dazukämen, die einfach stillschweigend erst dann zahlen, wenn ich sie frage, ob sie’s vielleicht vergessen haben (da ist mir sehr viel lieber, eine kurze erklärende Mail wie oben zu erhalten – immerhin besteht ja eine geschäftliche Partnerschaft, da kann man sowas ja auch offen sagen). Und selbst bei den Kunden, die im Zeitrahmen zahlen, ist inzwischen deutlich festzustellen, dass auch viele von denen, die früher mehr oder weniger direkt am Tag des Rechnungserhalts überwiesen haben, jetzt eher gegen Ende der Zahlungsfrist zahlen.

Ich weiß nicht, was schlimmer ist: Zu sehen, wie ich selbst trotz – laut Rechnungslauf – guten, sogar ansteigenden Umsätzen schlicht aufgrund sehr später Geldflüsse auf Rücklagen zurückgreifen muss und erstmals sowas wie eine Liquiditätsplanung machen muss, oder zu wissen, dass gleich eine ganze Reihe von Kunden im Moment dieses „Es ist ziemlich eng grad“-Gefühl mit mir teilen. Schön ist das nicht.

Nun, eine „Bitte“ ist es genaugenommen nicht. Vielmehr scheint der Kunde einen Blick in die Zukunft werfen zu können – oder versucht sich pendelschwingend als virtueller Hypnotiseur, wenn er seine Ankündigung, die Rechnung erst später begleichen werden, mit den Worten unterstreicht:

Selbstverständlich sehen sie derweil von etwaigen zusätzlichen Forderungen ab.
Danke für Ihre Nachsicht und mit freundlichen Grüßen

Sachen gibt’s …

SSL-Zertifikate gibt’s von einer Menge Anbietern. Wir nehmen unter anderem auch die Dienste von StartCom in Anspruch, bei denen wir am ehesten den Eindruck haben, dass die auch selbst was von Sicherheit verstehen – ein Eindruck, den fatalerweise viele SSL-Zertifizierungsstellen nicht machen.

Zu diesem Eindruck trägt auch bei, dass StartCom konsequent auf SSL-Client-Zertifikate zur Authentifizierung setzt, und nicht auf das klassische Paar aus Benutzername/Passwort. Technisch gesehen läuft das so, dass man einen kleinen Assistenten durchläuft, der eine Browserfunktion anwirft, die einen privaten Schlüssel direkt im Browser erzeugt und ablegt (sprich, er wird nie an den Website-Betreiber übermittelt) und anschließend auf dieser Basis dann ein Zertifikat generiert, was dann direkt in den Browser importiert wird. Ist der Prozess abgeschlossen, kann man sich mit diesem Zertifikat gegenüber der Website ausweisen. Im Prinzip ist das ein gutes Beispiel, wie man starke Authentifizierung wirklich bequem und einsteigerfreundlich machen kann, denn der ganze Prozess ist sehr einfach gestaltet und lässt sich auch ohne besondere Vorkenntnisse durchlaufen. Die Frage, die unerfahrene Anwender dabei noch am ehesten stellen, ist von daher weniger „Was muss ich hier machen?“, sondern eher „Wieso funktioniert das einfach so, ich musste ja nicht mal ein Passwort eingeben?!“ – tja, willkommen in der manchmal doch ganz schönen Welt von SSL.

Damals hatte ich diesen ganzen Prozess mit Firefox abgewickelt. Mittlerweile nutze ich im Alltag fast nur noch Chrome, genaugenommen die freie Variante Chromium, für die Tom „spot“ Calloway Fedora-Pakete pflegt. In puncto SSL unterscheidet sich Chromium von Firefox: Unter Linux benutzt es nämlich die NSS-Funktionalität des Systems, statt einen eigenen Keystore zu basteln (was ich für eine äußerst gute Idee halte), während Firefox auf allen Plattformen einen eigenständigen Keystore nutzt. Natürlich können die Client-Zertifikate in Form von PKCS#12-Dateien exportiert und im jeweils anderen Tool importiert werden – das nur so zum Hintergrund.

Nun laufen auch Client-Zertifikate irgendwann aus, so dass ein neues fällig wurde. Also habe ich den Client-Zertifikats-Assistenten von StartCom angeworfen – diesmal aber im Chromium. Nun ist aber gerade jenes „Certificate Enrollment“ derzeit noch eine Baustelle und läuft beileibe nicht „einfach so“ rund, wie ich es oben beim Firefox noch so gelobt habe. Und damit meine ich nicht, dass es mehr Handarbeit bräuchte, sondern dass es schlicht überhaupt nicht erfolgreich funktioniert. Hätte ich mal vorher nachgeschaut – hatte ich aber nun mal nicht.

Das vorläufige Ende vom Lied: Chromium hat es durchaus geschafft, einen privaten Schlüssel in der NSS-Datenbank zu erstellen. Mit dem Import des darauf basierenden Zertifikats hat das aber leider nicht geklappt: „Fehler 207 (net::ERR_CLIENT_CERT)“ war alles, was ich zu sehen bekam – sprich, das war ein Schuss in den Ofen – und zwar noch ein schlimmerer, als ich dachte: Die naheliegendste Lösung, den Key einfach wegzuschmeißen und ein neues Client-Zertifikat zu erstellen (diesmal dann wieder im Firefox) klappt nämlich auch nicht: StartCom lässt es nicht zu, ein Client-Zertifikat zu erstellen, wenn ein vorheriges noch gültig ist.

Dunkle Wolken ziehen am Horizont auf. Das von StartCom generierte Client-Zertifikat kann ich über deren Toolbox immer wieder beziehen; das ist nicht das Problem – nur funktioniert es eben nur in Kombination mit dem Key. Und das ist genau das Problem: Im Chromium (bzw. in der NSS-Datenbank) habe ich den Key, bekomme aber das Client-Zertifikat nicht rein. Der Firefox könnte zwar das Client-Zertifikat importieren, aber da er den Key nicht hat, schlägt das fehl.

Mein nächster Gedanke war: „Bei SSL-Server-Zertifikaten hantieren wir ja auch immer mit einer Datei für den privaten Schlüssel und einer Datei mit dem Zertifikat. Wieso also nicht einfach den Key aus der NSS-Datenbank exportieren und in Firefox importieren – und dann, wenn der Firefox den Key hat, kann er ja wohl auch das Zertifikat aus der Toolbox importieren.“

Denkste. Christopher wies mich direkt darauf hin:

Nein, Firefox kann nur Keys nur in PKCS-Dingsbums importieren, nicht roh. Also kannst es versuchen, aber bei Firefox…

Wäre ja nett gewesen, überhaupt bis zum diesem Punkt zu kommen. Faktisch ist es nämlich gar nicht möglich, nur den Key aus der NSS-Datenbank zu exportieren. Exportieren geht nur im PKCS#12-Format, und das besteht zwingend aus Key und Zertifikat. Nelson B Bolyard schreibt:

Bare private keys by themselves?
NSS utility programs are intended to NOT do that.
The idea is to NOT make it easy for the user to ruin his own security.

Ja, toll. Ich will aber nicht meine Security ruinieren; ich weiß ja, was ich hier tue und warum. Und ich habe mir beileibe auch nicht aus freien Stücken ausgesucht, so vorzugehen. Chris ergänzt: „Abandon all hope, ye who enter here“. Wie wahr.

So oder so: Dieser Weg war wohl ein Schuss in den Ofen. Also vielleicht doch anders herum, sprich, „irgendwie“ an das Zertifikat kommen und das manuell in die NSS-Datenbank mit reinpacken. Nur wie? Erstmal müsste man dazu wissen, wie denn die URL heißt, unter der man das Zertifikat bekommen kann. Und das ist nicht so ganz einfach, denn die Toolbox vom StartCom ist völlig ajaxisiert; man kann sich nicht einfach irgendwo mal schnell eine URL rauskopieren. Abhilfe schafft das Firefox-Plugin Live HTTP Headers, das die HTTP-Header jeglicher Browserkommunikation mitschneidet – also auch die der Ajax-Kommunikation. Und siehe da: Klappt prima, und ich komme auf eine URL in dieser Form:

https://www.startssl.com/getcrt.ssl?certID=...

Genau was ich brauche!

Leider ist es damit nicht getan, denn Firefox versucht beim Aufruf dieser URL sofort, das Zertifikats zu importieren – was natürlich nicht geht, weil der dazu passende private Schlüssel im Keystore vom Firefox ja fehlt. Ich will das Zertifikat ja auch eigentlich nicht importieren, sondern herunterladen, sprich: als Datei speichern. Das Problem kann man grob damit vergleichen, wenn man die URL eines Bilds direkt im Browser eingibt: Dann wird man ja auch nicht gefragt, ob man das Bild anzeigen oder speichern will, sondern es wird eben einfach angezeigt. Mit einem entscheidenden Unterschied: Ich kann dann immer noch über das Kontextmenü „Bild speichern unter …“ auswählen und das Bild auf die Platte bannen. Hier wird aber ja gerade gar nichts angezeigt – ergo hilft mir das Kontextmenü (und auch das Datei-Menü, das einen gleichnamigen Punkt bietet) überhaupt nicht weiter.

Der Workaround, auf den ich schließlich gekommen bin, gehört zu der Kategorie, bei der man sich mit einem herzhaften „D’oh!“ an die Stirn schlagen möchte. Also: Wo kann man sonst noch über das Kontextmenü Dinge direkt abspeichern? Richtig, bei Links, „Ziel speichern unter …“. Zwar ist die StartCom-Toolbox wie gesagt ajaxisiert und bietet daher keinen solchen Link, aber das macht nichts: Da wir ja nun die URL kennen, bauen wir uns einfach selbst einen Link in einer lokalen Datei, rufen diese via file:///tmp/link.html im Firefox auf, rechte Maustaste auf den Link, Ziel speichern unter, und voilà: Das Zertifikat ist im PEM-Format mit der Endung .p7b auf der Festplatte gespeichert.

Damit ist die größte Klippe umschifft. Nun gilt es nur noch, diese Datei in die NSS-Datenbank zu importieren, wo bereits der zugrundeliegende Key wartet:

certutil -d sql:$HOME/.pki/nssdb -A -t "u,u,u" -n "Jonas Pasche" -i cert.p7b

Klappt sofort – und spontan kann Chromium das SSL-Client-Zertifikat benutzen. Der Vollständigkeit halber soll es aber auch in den Firefox. Also exportieren wir es aus der NSS-Datenbank; um genau zu sein, exportieren wir Zertifikat und Key, denn es gibt ja nur beides in Kombination:

pk12util -d sql:$HOME/.pki/nssdb -o export.p12 -n "Jonas Pasche"

Die resultierende Datei kann dann schließlich problemlos in Firefox importiert werden – und ein ätzendes Problem mit einem zunächst verwaisten Key in der NSS-Datenbank hat seinen sauberen Abschluss gefunden.

Bleibt noch zu sagen, dass dieser ganze Krampf rein akademischer Natur war. Es hätte nämlich auch gereicht, sich in der StartCom-Toolbox ein neues Client-Zertifikat mit einer anderen E-Mail-Adresse generieren zu lassen. Entscheidend für die Anmeldung an der Toolbox ist schließlich nicht die Mail-Adresse, sondern die damit verbundene Identität, und da sämtliche Client-Zertifikate, die ich in meinem Account ausstelle, auch auf meine Identität verweisen, kann ich auch alle gleichermaßen für den Login benutzen. An dieser Stelle soll nicht unerwähnt bleiben, dass diese letzte – natürlich viel einfachere – Variante dem wie immer hervorragenden StartCom-Support eingefallen ist. Danke dafür!

Neulich war ich mal wieder in der Situation, ein seltsames eMail-Zustellungsproblem debuggen zu müssen. Genau genommen hatte mir jemand eine eMail geschickt, die aber nie bei mir angekam. Statt dessen erhielt er nach zwei Tagen eine Bouncemail und wandte sich daraufhin an mich mit der Frage, warum unser Server seine eMail nicht angenommen hätte. Ich ließ mir die Bouncemail zeigen und schon bald stellt sich heraus, daß er sich bei meiner eMail-Adresse vertippt hatte (genau genommen bei der Domain). Das Rätsel war nun, warum ihm sein Mail-Programm dies nicht sofort oder zumindest sehr zeitnah nach dem Absenden der Mail mitgeteilt hat. Des Rätsels Lösung erfordert einen kleinen Exkurs:

Es ist seit einigen Jahren leider üblich geworden, daß Provider an der DNS-Infrastruktur des Internets rumpfuschen. Das Domain Name System (DNS) ist bekanntlich dafür verantwortlich Hostnamen wie blog.jonaspasche.com in IP-Adressen aufzulösen. Dieser Dienst ist für das Funktionieren des Internets wie wir es kennen so essentiell, daß Störungen und Manipulationen am DNS in der Regel mit der sonst allzu oft bemühten Umschreibung „das Internet ist kaputt“ in der Tat ausnahmsweise gut umschrieben sind. Zuletzt spürbar wurde dies, als die für den „.de“-Bereich zuständige DENIC im Sommer dieses Jahres eine massive Störung hatte die dazu führte, daß DNS Server für den größten Teil der Domains im „.de“-Bereich fälschlicherweise die Information ausgaben, die Domains existieren schlicht nicht. Sehr viele deutsche Webseiten waren nicht mehr erreichbar und etliche eMails gingen verloren, es dauerte in den meisten Fällen Stunden, vereinzelt sogar Tage, bis alle Folgen der Störung behoben waren — und das bei einer Störung die offenbar in unter einer Stunde bemerkt und behoben wurde. Das DNS ist in der Tat eines der kritischsten Systeme im Internet.

Was genau tun nun also Provider, das man als herumpfuschen bezeichnen könnte und was ist die Folge, wenn das DNS doch so wichtig ist? Nun, es geht dabei um einen speziellen Fall im DNS, der immer dann eintritt wenn jemand versucht einen Hostnamen aufzulösen, den es nicht gibt. Die korrekte Antwort die man in so einem Fall von DNS erhalten möchte ist natürlich, daß es den Hostnamen nicht gibt, technisch: NXDOMAIN (für Deutsche gut als NIX-DOMAIN zu merken). Die meisten modernen Browser melden dies dem User mittlerweile mit einer verständlichen Fehlermeldung, einige bieten sogar direkt an nach ähnlichen Hostnamen in den einschlägig bekannten Suchmaschinen zu suchen.

Vor einigen Jahren erregte Verisign (deren Geschäft ist neben dem Ausstellen von Sicherheitszertifikaten z.B. für den bekannten HTTPS-Service vor allem der Betrieb eines guten Teil der DNS-Infrastruktur) großes Aufsehen, als sie damit begannen bei nicht existenten Hostnamen nicht mehr korrekt NXDOMAIN zu melden, sondern statt dessen die IP-Adresse eines ihrer Server herausgaben. Wenn man zufällig versucht hatte, mit dem Browser einen Hostnamen für eine Webseite aufzulösen, bekam man dann eine andere Webseite als die gewünschte angezeigt auf der einem die nicht gefundene Domain zum Kauf angeboten wurde. Alle anderen User (z.B. diejenigen die gerade eine Mail senden wollten) schauten in die Röhre, denn ihr Programm hat diese „Serviceleistung“ von Verisign natürlich nicht verstanden und es kam zu Fehlern. Das Ende vom Lied war, daß Verisign diesen „Service“ nach langen Protesten schließlich wieder eingestellt hat.

Aber weil schlechte Beispiele nunmal Schule machen, kamen seitdem haufenweise Netzzugangsprovider auf die glorreiche Ideen den Unsinn nachzumachen und ihrerseits den Usern ungefragt Domains zum Kauf anzubieten oder auch schlicht ihnen unerwünschte Werbung anzuzeigen. Das ganze wäre lediglich ärgerlich, wenn es nicht haufenweise Fehler verursachen würde. Eines der anschaulichsten Beispiele ist die Problematik bei eMails, die auch bei meinem Bekannten zugeschlagen hatte. Dessen Mailprogramm hat nämlich den vertippten Hostnamen aufgelöst und statt einer korrekten Fehlermeldung (NXDOMAIN eben) eine IP erhalten –- und folgerichtig versucht die eMail dorthin zuzustellen. Nur antwortete unter dieser Adresse natürlich kein Mailserver, also hat es die Mail zurückgestellt und es später nochmal versucht. Dieses Spiel wiederholte sich dann zwei Tage lang, bis das Mailprogramm schließlich aufgegeben hat und die Mail bouncen lies. Hätte der Netzzugangsprovider meines Bekannten nicht im DNS rumgepfuscht, hätte es schon kurz nach dem Absenden der Mail eine Fehlermeldung gegeben, die in (hoffentlich) etwas verständlicheren Worten ausgedrückt hätte, was NXDOMAIN nunmal bedeutet: die Domain die Du da genannt hast gibt es nicht. — Meinem Bekannten wäre der Fehler dann vermutlich sogar aufgefallen.

Wie schon angedeutet können derartige Manipulationen am DNS noch ganz andere Fehler zur Folge haben, die sich von Anwendung zu Anwendung zum Teil stark unterscheiden. Unter anderem wird auch eine bestimmte Methode der Spam-Bekämpfung dadurch behindert, bei der der empfangende Mailserver im DNS nachschaut, ob der andere Server der sich da gerade bei ihm gemeldet hat im DNS verzeichnet ist und daher eventuell kein Spammer sein könnte.

Letztlich gibt es zu dieser Marketing-Idee nur zu sagen, daß es auf Sabotage hinausläuft. Jeder der so etwas implementiert und nicht frei von Sachverstand ist, sollte nach kurzem Nachdenken bemerken, was für eine schlechte Idee das ist.

Was kann man also tun? Nun, wenn man statt eines kleinen Plasterouters zum Beispiel einen Mini-PC oder etwas in der Art als Router betreibt, kann man darauf einen lokalen DNS Resolver betreiben. Der übernimmt dann die Aufgabe der normalerweise vom Netzzugangsprovider bereitgestellten DNS Resolver und ist frei von solchen Manipulationen, da er die DNS Resolver des Providers gar nicht fragt, sondern alles selbst auflöst. (Diese Methode schützt allerdings nicht vor Manipulationen durch Verisign oder andere Betreiber von Root-Nameservern — aber bei denen sind diese Manipulationen zum Glück wieder unüblich geworden.)

Wer nur einen Plastikrouter hat, kann überlegen diesen mit DD-WRT oder OpenWRT zu bespielen (dabei geht allerdings die Garantie verloren) und kann dann dort einen DNS Resolver installieren. Anleitungen gibt es im Internet zuhauf. Für unsere Lieblings-DNS-Software djbdns gibt es sie hier (vorher muß man djbdns natürlich erstmal installieren). Alternativ hat man auch die Möglichkeit auf seinem eigenen Rechner lokal einen Resolver zu betreiben.

Und es gibt für einige Kunden von Netzzugangsprovidern noch einen dritten Weg: OptOut. Ich hab zufällig einen Heise-Artikel zum Thema entdeckt, auf dessen letzter Seite erwähnt wird, daß man bei T-Online, Alice und Versatel im Kunden-Webinterface diese Manipulation abstellen kann. Das ist immerhin etwas, auch wenn ich natürlich finde, wenn dann sollte es hier eins OptIns bedürfen und nicht umgekehrt.

Erfreulicherweise hab ich bei dieser Gelegenheit festgestellt, daß die Versatel diese Funktion bei mir schon von vornherein abgestellt hat — was daran liegen könnte, daß ich beim Bestellen des Anschlusses erwähnt habe, daß ich ITler bin und über diesen Anschluß arbeiten werde. Vielleicht war es auch nur ein Zufall, vielleicht verfährt die Versatel mittlerweile auch immer so, was ich natürlich sehr begrüßen würde.

Einen lokalen DNS Resolver betreibe ich natürlich trotzdem, schon alleine aus Sicherheitsgründen und damit DNS in meinem Heimnetzwerk performanter läuft. Ein Nebeneffekt der ganzen Geschichte wäre auch gewesen, daß mich das sogenannte „Zugangserschwerungsgesetz“ nicht betroffen hätte, wenn es denn umgesetzt worden wäre. Aber ich betreibe den DNS Resolver nicht deswegen und hab ihn auch schon viel länger als es dieses dumme Gesetz gibt.

Meine eMails kommen jedenfalls an oder bouncen, so wie es sich gehört.

– „Hallo liebes $Steuerbüro das bis 2008 meine Buchhaltung gemacht hat, bis inklusive 2007 habe ich ja meine Belege bei mir, aber die aus 2008 müssten noch bei Ihnen liegen. Könnten Sie mir die bitte zusenden?

– „Na klar, wobei, ich sehe gerade, Ihre Lohnbuchhaltung ab 2005 liegt ja auch noch hier. Ich schick Ihnen die mal schnell mit.“

Ahja, vielen Dank auch. Ich bin dann mal weg. Neues Regal kaufen.

Hin und wieder haben wir Gelegenheit, einige Domains von anderen Providern zu übernehmen, und wenn jene kooperativ sind, bekommen wir die bestehenden DNS-Zonendateien bereitgestellt. Umgekehrt tun wir das genauso; das ist einfach ein Zeichen guten Stils. Wenn eine Domain wegziehen soll, dann ist die Entscheidung ja schon gefallen; da muss man dem Kunden und dem neuen Provider ja nicht absichtlich Knüppel zwischen die Beine werfen, in dem man ihm die Übernahme der DNS-Daten künstlich erschwert.

Bei den meisten Domainübernahmen zu uns bekommen wir BIND-Zonendateien. Wie vielleicht schon bekannt ist, setzen wir jedoch tinydns als DNS-Server ein. Besteht die Möglichkeit, Zonen per AXFR zu übernehmen, so bevorzugen wir dies, aber gängiger ist, dass wir ein Bündel BIND-Zonen einfach zugemailt bekommen.

Gut, dass Dan Erat das Tool bind-to-tinydns geschrieben hat, das BIND-Zonen interpretieren und ins tinydns-data-Format übertragen kann. Es erwartet seine Eingabe auf STDIN und schreibt das Ergebnis in eine Datei. Dabei werden entsprechend ein SOA-Record („Z“) und mehrere NS-Records („&“) angelegt, was nun entsprechend noch geändert werden muss: Wir bevorzugen, die NS-Records mit „.“-Syntax anzulegen, wobei tinydns dann automatisch einen SOA konstruiert. Und so machen wir’s:

for FILE in hosts.* ; do
  ZONE=`echo $FILE | sed 's/^hosts\.//'` ;
  cat $FILE | bind-to-tinydns $ZONE $ZONE.pre $ZONE.tmp ;
  rm -f tinydns/$ZONE ;
  for NS in 1 2 3 ;
    do echo ".$ZONE::ns$NS.jonaspasche.com" >> tinydns/$ZONE ;
  done ;
  grep -v -E "^(Z|&)$ZONE\.?:" $ZONE.pre >> tinydns/$ZONE ;
done

Sprich: Da die Dateien alle im Format hosts.domain.tld benannt sind, ziehen wir uns den Namen der Zone aus dem Dateinamen. Wir konvertieren die Zone mit bind-to-tinydns in eine $ZONE.pre (die noch die ursprünglichen SOA-/NS-Angaben trägt); anschließend legen wir in einer Schleife die drei neuen NS-Records an und fügen schließlich den Inhalt der konvertierten Zone ein, wobei wir den SOA und die bisherigen NS-Delegationen weglassen. Dabei achten wir darauf, nur die NS-Records der Zone selbst wegzulassen – andere „&“-Einträge, die sich auf Subdomains beziehen (die damit auf andere Nameserver delegiert werden), bleiben natürlich bestehen.

Schließlich haben wir im Verzeichnis tinydns fertige Zonendateien liegen, angepasst auf unsere DNS-Server. Das war’s auch schon!