Technik

Nachdem wir vor knapp zwei Wochen PHP 5.3.9 eingeführt haben, ist es auch schon wieder vorbei damit:
Wir haben es gestern in einer Nacht- und Nebel-Aktion aus dem Programm genommen.

Ursache hierfür war der CVE-2012-0830 - eigentlich wollten die PHP-Entwickler in der Version 5.3.9 eine Lösung zum Verhindern von DOS-Angriffen mittels Hash-Kollisionen anbieten (CVE-2011-4885), was sie durchaus auch getan haben, nur öffneten sie damit - ich behaupte mal "ausversehen" - entfernten Angreifern Tür und Tor. Die Details spare ich mal aus.

Nachdem gestern Abend dann PHP in der Version 5.3.10 released wurde, die nur dieses Problem adressiert, haben wir sie kurzerhand in unseren Build-Tree aufgenommen, die Patches der Vorgänger-Version gemerged und 5.3.9 durch die neue Version auf unseren Servern ersetzt.

Ich mag solche Aktionen

Am Wochenende habe ich (eher privat) ein wenig in PHP gebastelt.

Irgendwann kam ich zu dem Punkt, wo ich gerne über ein UDP-Socket Multicast-Nachrichten empfangen und verarbeiten wollte. Leider musste ich feststellen, dass die dazu notwendige IP_ADD_MEMBERSHIP-Option nicht für Sockets oder Streams zur Verfügung steht. Vor 6 Jahren gab es wohl einen Ansatz um diese Funktionalität im PHP selbst zu implementieren, aber daraus ist bisher nichts geworden und der Author resignierte enttäuscht. So wie es aussieht, werde ich bis PHP 5.4 warten müssen.

Jetzt hatte ich aber keine Lust, diesen Patch für den Moment zu übernehmen und in die PHP's die ich nutze einzukompilieren. Deswegen habe ich gestern im Zug von Düsseldorf nach Stuttgart meine erste PHP-Erweiterung geschrieben und entsprechende Funktionalität (IP_ADD_MEMBERSHIP, IP_DROP_MEMBERSHIP, IP_MULTICAST_IF, IP_MULTICAST_LOOP und IP_MULTICAST_TTL) bereitgestellt, die Sockets in Richtung Multicast modifiziert.

Die schwierigste Aufgabe dabei war zu erkennen, ob es sich um "Sockets" (PHP-Erweiterung "Sockets") oder "Streams" (z.B. via "stream_socket_client") handelt und dementsprechend die passenden Descriptoren zu finden. In letzterem Falle habe ich immernoch die Vermutung, dass meine Erweiterung hier zu einem Segfault führen könnte - das ist der Entwickler dann aber selbst schuld

Veröffentlicht habe ich die Erweiterung noch nicht - PHP mag grundsätzlich wohl nicht so wirklich die GPL, sodass ich mir über eine alternative Lizenz Gedanken machen werde, vermutlich was BSD-ähnliches. Wer Interesse an der Erweiterung hat, kann mir da ja auf die Füße treten

Ganz vergessen zu erwähnen:

Wir haben seit Montag PHP 5.3.9 im Angebot! Wer es also nutzen mag, ist herzlich eingeladen eine fixe E-Mail an den Support zu schicken.

Zum Anfang des nächsten Monats hin werden wir PHP 5.2 aus dem Programm nehmen und für Neukunden erst einmal nur noch 5.3.x ausrollen. Genau wie seinerzeit mit 5.1 bleiben Bestandskunden allerdings in ihrer bestehenden PHP-Version und werden nur nach Absprache upgegradet. Gerade zwischen 5.2 und 5.3 hat sich ja sehr viel getan, sodass ein solcher Schritt schon als recht invasiv zu bezeichnen ist.

Zwischen den Feiertagen hatte ich dann auch wie bereits angekündigt mal einen RC von PHP 5.4 gebastelt bzw. kompiliert. Hat recht gut funktioniert, wenn man davon absieht, dass ich den Suhosin-Patch nicht dorthin portiert bekommen habe (allerdings waren die Versuche hier auch recht herzlos) und die Extension "bcompiler" gegenwärtig auch inkompatibel zu den Objekt-Erweiterungen in 5.4 (hier primär die Traits) zu sein scheint - da werde ich wohl die "richtigen" Entwickler zum Zuge kommen lassen
Schade auch, dass ich sonst keine Zeit hatte mir die neue Version mal im Betrieb anzuschauen, bisher wartet sie noch darauf mal als CGI oder CLI verwendet zu werden.

Ich habe gestern Nacht einen neuen Patch für WordPress 3.3 zusammengeschrieben, da mehr und mehr Kunden (aber auch nicht-kunden) ihre Installation updaten wollten und wieder auf diesen Speicherhunger gestoßen sind.

Mit dem neuen Patch bin ich allerdings einen anderen Weg gegangen als in den vorhergehenden Versionen:
Anstelle die Datei wp-includes/l10n.php aufwändig zu patchen, habe ich eine eigene Klasse erstellt, die die PoMo-Klasse "MO" simuliert. Lädt man die Klasse nun also vor der eigentlichen, benutzt WordPress fortan die native GetText-Schnittstelle. Ist kein GetText vorhanden, wird der Patch automatisch nicht geladen.

Durch die neue Klasse ist es lediglich notwendig eine einzelne Zeile zum ursprünglichen WordPress-Code hinzu zu fügen (siehe Diff ganz unten), alles andere geschieht unabhängig. Da die MO-Klasse API-Bedingt nie weiß, in welcher Text-Domain sie gerade arbeitet und WordPress sowieso das "mergen" von Sprachdateien benötigt, ist das Handling an dieser Stelle etwas "chaotisch" und undurchsichtig geworden - funktioniert jedoch recht problemlos und lässt meines Wissens nach keine Wünsche der Entwickler offen (zumindest nicht solche, die im Trac von WordPress geäußert wurden).

An dieser Stelle möchte ich mich auch noch bei Linus bedanken, dass er bzgl. des Trac jede Menge Arbeit und Zeit investiert hat und auch weiterhin tut. Mir war es ja wichtig, dass ich das nicht auch noch übernehmen muss

Ach ja: Den Patch samt allen weiteren Dateien gibt es unter

http://oss.tiggerswelt.net/wordpress/3.3.0/

Jeder Interessierte ist herzlich eingeladen den Patch zu nutzen (bzw. zu testen). Support ist recht schwer, da es sich um ein kostenfreies Angebot handelt und ich momentan mehr als gut ausgelastet bin. Allerdings sollte da auch nicht so viel notwendig sein - die INSTALL-Datei gibt kurz Anweisung und sobald es läuft, sollte es laufen (naiv gesagt)

Nachtrag (27.12.2011, 17:12):

Der neue Patch hatte einen nicht-fatalen Schreibfehler in Zeile 217 der Datei /wp-includes/pomo/native.php der zu Problemen mit Sonderzeichen geführt hat. Der Fehler ist behoben! Jeder, der den Patch vorher installiert hat, sollte die native.php erneut einspielen. Vielen Dank an Schrottie für die Zusammenarbeit in dieser Sache!

Ich weiß schon genau, was ich mir zu Weihnachten wünsche:

PHP 5.4

Ist zwar ein rein privater Wunsch, aber das neue Release wird ja bereits seit Wochen hoch gelobt und wird neben massiven Verbesserungen der Performance auch das absolute "Haben-Will-Feature" Traits enthalten.

Bisher bin ich schon ein wenig davor zurückgeschreckt einen der Release-Candidates zu kompilieren (bzw. hatte einfach keine Zeit für sowas), aber wenn es vor Weihnachten kein Final Release gibt, werde ich das wohl über die Feiertage mal machen. Mir kribbelts schon förmlich in den Fingern!

Gestern erwähnte jemand auf einer Linux-User-Group-Mailinglist die sog. WebSockets.

So gesehen nichts neues, hatte ich schon von gehört und für recht gut befunden. Nur lässt die Adaptierung in der Browser-Welt noch auf sich warten bzw. brauch es wohl noch 1-2 Jahre bevor man über was produktives mit WebSockets nachdenken kann.

Aber irgendwie hat es mich dann doch gefuchsed. Nun lese ich schon die zweite Mittagspause lang das das Protocol Draft und habe so eine leichte Vermutung, wo das hinlaufen wird... Naja, ob das gut ist? Aber es passt so ein wenig zu meiner Wochenend-Aktion mit BOSH, zumal es auch schon die ersten Ansätze gibt XMPP und WebSockets zu vereinen (einfach suchen, findet man sofort).

Eine der Sachen, die man mir negativ zur Last legen könnte, ist der Umstand, dass ich manchmal so wahnsinnig viel an so wahnsinnig vielen verschiedenen Dingen arbeite - das weiß ich! Um so schöner ist es dann doch, wenn man spontan ein paar dieser vielen Dinge nimmst und sie in einem kleinen Stück Software miteinander verbindet.

So geschehen an der Nacht von Samstag auf Sonntag, als die Dame des Herzens bereits am Schlafen war und mich so eine Lust überkam irgendwas zu "arbeiten". Man nehme also die XML-Stream-Komponente aus meiner XMPP-Library und verknüpfe sie mit der HTTP-Server-Komponente meiner Event-API und erhalte einen "BOSH-Dienst" frei nach XEP-0124!

Sehr toll!

Da ich jedoch noch nicht sonderlich viel Zeit rein investiert habe, kann das Ding noch nicht viel, so fehlen z.B. jegliche Timeouts, sodass Sessions die nicht explizit geschlossen werden für immer bestehen bleiben. Aber das bisherige Ergebnis hat mich irgendwie so erfreut, dass ich bestimmt noch die eine oder andere Nacht hier investieren werde.

Mit Hilfe von jQuery UI und Strophe.js habe ich dann noch einen kleinen XMPP-Client in HTML5 gebastelt, der immerhin schon Nachrichten senden und empfangen kann.

So ist es dann wieder sinnvoll über die Zeit "viele kleine Dinge" zu bauen, wenn man sie später zu "etwas größerem zusammensetzt".

Heute Mittag war die Freude hier im Büro groß, als das CVE-2011-3192 von Mittwoch ein Update erfuhr. Konkreter Hintergrund war hier, dass sich die alte Meldung nur auf den "Range"-Eintrag im HTTP-Header bezog, nun aber auch vor dem "Request-Range"-Header gewarnt wird - die erwähnte Freude beruhte auf dem Umstand, dass unser eigenes Modul zur Behebung des Problems von Mittwoch bereits dieses Update mit abdeckte, und führte zu einem regelrechten Schulterkopfen.

Sowohl das Update des CVEs aber auch der Umstand, dass wir es schon abdecken, liegt auf der Hand, wenn man sich den entsprechenden Quelltext des Apache-Webservers anschaut:

In Zeile 3162 der Datei modules/http/http_protocol.c wird der Range-Header ausgelesen und später weiterverarbeitet. Existiert dieser Eintrag nicht, so versucht Apache den Request-Range-Header zu rate zu ziehen. Da wir just diese Zeile gelesen hatten, bevor wir das Modul entwickelt haben, lag es auf der Hand diesen zweiten Fall also auch mit abzudecken.

Heute mittag vermeldete Heise Online, dass der Apache-Webserver mit einem einzigen Computer außer Gefecht zu setzen ist. An dieser Stelle erst einmal vielen Dank an Benedikt für das "Bekanntmachen" des Links

Das Problem betrifft alle Apache-Versionen (1.3, 2.x). Wir konnten es recht schnell nachvollziehen und haben kurzum auch ein eigenes Tool zum Testen CVE-2011-3192 geschrieben (schlichtweg weil meine Perl-Installation keinen Fork-Manager hat) mit dem es sich auch reproduzieren ließ. Einen offiziellen Patch für Apache scheint es noch nicht zu geben, wenngleich auch einige Lösungsansätze in der Diskussion sind.

Sei es das Schützen des Webservers mittels SetEnvIf:

SetEnvIf Range (,.*?){5,} bad-range=1
RequestHeader unset Range env=bad-range

... LimitRequestFieldSize:

LimitRequestFieldSize 200

... mod_rewrite:

RewriteEngine On
RewriteCond %{HTTP:range} !(^bytes=[^,]+(,[^,]+){0,4}$|^$)
RewriteRule .* - [F]

... oder mod_header: 

RequestHeader unset Range

Alternativ lässt sich das Problem auch über ein zusätzliches Modul beheben, sei es über das, dass wir selbst heute geschrieben haben, oder ein relativ ähnliches von einem Apache-Entwickler.

Wir raten ein entsprechendes Apache-Modul zu benutzen oder das Problem mittels mod_rewirte bzw. SetEnvIf zu adressieren! 

Im Rechenzentrum braucht unser neues Linux-System 3 Sekunden zwischen Starten der virtuellen Maschine und dem per SSH erreichbar sein.

Unglaublich.

Bei uns ist momentan wahnsinnig viel im Umbruch - daher auch die geringe Anzahl an Blogposts in der letzten Zeit. Vieles an Software, die wir einsetzen oder in den letzten 8 Jahren (6 Jahre davon für tiggersWelt.net), ist mittlerweile obsolet - gerade wenn es um die eigenen Komponenten geht hat sich das Denken ein wenig weiterentwickelt und irgendwann kommt der Punkt, wo mal was neues her muss.

Bis dato haben wir auf unseren Servern stets auf eine "richtige" Linux-Distribution gesetzt, darauf aber immer Rückbau betrieben und unsere eigene Software bzw. selbst kompilierte Versionen drüber gespielt. Wenn ich gefragt wurde, was wir denn im konkreten einsetzen passte meist die Antwort "Was eigenes und den Kernel von Distribution X". So wirklich zufrieden gestellt hat mich das nie. Zumal es komisch ist, einen Server zu installieren und gleich wieder bestimmte Komponenten zu deaktivieren oder zu deinstallieren. Ein Build-System habe wir mittlerweile ohnehin vorzuweisen, also warum nicht auch die notwendigen Komponenten wie Kernel oder Compiler selbst bauen, ein wirklicher Overhead existiert hierbei nicht mehr und wir reden eigentlich auch nur von 6 zusätzlichen Software-Paketen.

So habe ich heute die Ehre den ersten "Release-Kandidat" unseres eigenes Linux-Betriebssystems zwischen den Fingern zu haben und testen zu dürfen und es ist toll: Sehr minimal gehalten, das Basis-System (ohne Webserver) kommt mit ca. 20 MB Arbeitsspeicher aus und bootet selbst über Netzwerk binnen weniger Sekunden. Das System konfiguriert sich voll automatisch (sofern gewollt) anhand bestimmter Parameter wie z.B. MAC-Adresse der Ethernet-Interfaces oder UUID den XEN- bzw. VMware-Gastes.

Ich bin mal gespannt, wann der erste produktive Server damit bestückt wird. Vermutlich wird das noch nicht direkt ein Kundensystem sein, sondern eher sowas wie der Server, der hinter unseren Webseiten (u.a. auch dem Blog hier) steht. Ich bin gespannt =)

Ich bin ja ein bekennender gettext-Fan - intern arbeiten wir nur noch damit und schreiben neben dem Source-Code auch alle Programmtexte auf Englisch und übersetzen sie im Anschluss mittels gettext. Auch für WordPress schrieb ich ja einst einen Patch um von der dort verwendeten PoMo-Implementation wegzukommen. Da wir gerade für einen Kunden ein Wordpress installieren, mussten mir heute morgen zwei "TODO"-Einträge in meinem Code auffallen. Die hatte ich total vergessen.

Beide behandelten das Arbeiten mit sog. Kontexten (msgctxt). Mit Kontexten kann man noch einmal zwischen den Übersetzungen differenzieren - je nach Zusammenhang halt. gettext definiert hierfür u.a. die Funktion pgettext() und die ganzen Abarten wie z.B. dpgettext(). Nun besteht allerdings das Problem, dass z.B. die gettext-Bibliothek von PHP diese Funktionen (bzw. Makros) nicht bereitstellt und dementsprechend keine Kontexte zur Verfügung stehen - daher auch die "TODO"s in meinem Code.

Ich habe mir daher die Mühe gemacht einmal ein wenig im gettext-Source-Code zu stöbern und zu schauen, ob man das nicht irgendwie nachbauen kann. Man kann!

Im übersetzten Dictionary besteht der Lookup-Key aus dem Namen des Kontextes, dem ASCII-Zeichen 0x04 und dem eigentlich gesuchten Text. Diesen Key wirft man dann einfach gegen die gettext()-Funktion. Wichtig hierbei ist nur noch zu schauen, ob der Rückgabewert dem Eingabewert entspricht, denn dann sollte man nur den gesuchten Text zurück geben. In PHP sieht das in etwa so aus:

<?PHP

  function pgettext ($Context, $Text) {
    $lookup = $Context . "\x04" . $Text;
    $translation = gettext ($lookup);

    return ($translation == $lookup ? $Text : $translation);
  }

?>

Einen Tick komplizierter wird es beim Arbeiten mit der Plural-Version:

<?PHP

  function npgettext ($Context, $Singular, $Plural, $Number) {
    $lookup = $Context . "\x04" . $Singular;
    $translation = ngettext ($lookup, $Plural, $Number);

    if (($translation == $lookup) || ($translation == $Plural))
      return ($Number == 1 ? $Singular : $Plural);

    return $translation;
  }

?>

Man merke: Der Lookup-Key ist der Kontext und die Singular-Version des Textes, schlägt die Übersetzung "fehl" sollte - zumindest laut Source-Code von gettext - die Anzahl noch einmal in Betracht gezogen werden und der Rückgabewert dementsprechend gestaltet werden.

Soviel zur Dokumentation. Der Wordpress-Patch wurde in den Versionen für 3.1.2 und 3.1.3 bereits angepasst.

Gestern fragte ein Kunde bei Jabber/XMPP an, warum

Irgendwie lässt mir das Thema "Sicherheit im Webhosting" gerade keine Ruhe, das Mailing von gestern Abend drehte sich auch nur herum...

Wir haben eine Software entwickelt und in unser System integriert, die anhand einer CVE-Datenbank Verzeichnisse auf unseren Webserver scannen und erkennen kann, ob sich dort Software befindet, die mit bekannten Sicherheitslücken behaftet ist. In Zukunft sollen Kunden bequem auswählen können, ob die Software regelmäßig bestimmte Domains prüfen und Warnungen verschicken soll, wenn sie etwas findet.

Bis dahin brauchen wir noch ein paar Testfälle! Darum möchte ich mit diesem Posting Kunden suchen, die Webhosting bei uns haben und gerne mal Ihren Webspace durchgescanned hätten. Vorher aufräumen ist ungern gesehen, nachher (bei Bedarf) umso lieber
Wer Interesse hat, darf sich gerne per E-Mail bei mir melden.

Nachtrag (19:29): 5 Kunden getestet, 16 potentielle Sicherheitslücken auf 14 Domains gefunden - der Dienst ist mehr als nur notwendig. 

Sofern es meine Freizeit es in den vergangenen Wochen zuließ - und das war echt selten - habe ich mich daran gemacht einen abstrakten Gateway zu basteln, d.h. ich habe ein Stück Software geschrieben, das eine einheitliche API bereitstellt um einen IM-Gateway für XMPP zu bauen. Ich habe sowas ja schon mal für ICQ gebaut, das war mir aber zu sehr spezifisch bzw. zu wenig für andere Zwecke anpassbar.

Einen ersten Testfall habe ich gestern Abend bei einem schönen Glas Wein gleich mal ausprobiert:
Ich habe den Gateway gegen eine abart von Skype-Library laufen lassen und war doch prompt im Stande Präsenz-Informationen auszutauschen und über Skype zu chatten.

Bevor jetzt aber jeder schreit "Wir haben einen Skype-Transport!" - ein paar Nachteile hat die Sache dann doch: Ich kann mich nur mit "Skype for Business"-Accounts verbinden, "Skypen" bzw. Telefonieren geht natürlich nicht, es kostet Lizenzgebühren, die Zukunft von Skype ist ungewiss - besonders was das Linux-Umfeld angeht - und irgendwie fühle ich mich auch nicht sonderlich danach es Open Source zu machen. Es wird wohl mehr eine private Spielerei bleiben. Aber trotzdem erwähnenswert :)