Martin's Blog

In Qt 4.4 wurde die von KHTML abstammende Rendering-Engine WebKit integriert. Um diese richtig ausprobieren zu können, hat Trolltech einen Demo-Browser geschrieben. Dieser ist nun die Grundlage für einen neuen Browser: Arora
Hier die Highlights:

• Steht unter der GPLv2
• Benutzt WebKit als Rendering-Engine
• Plattformunabhängig, da auf Qt aufbauen
• Anpassung an das System, da auf Qt aufbauend
• Komplett neue Möglichkeiten für Webseite Entwickler, da QWidgets in die Webseite integriert werden können

Der Browser befindet sich noch unter starker Entwicklung, so gibt es zum Beispiel noch keine Unterstützung für Netscape Plugins, aber das wird. Abgesehen davon kann man das Fehlen von Flash durchaus als Feature bezeichnen 😀

Ich finde die Entwicklung sehr interessant. Wer mich kennt, weiß ja, dass ich Mozilla Firefox aus verschiedenen Gründen ablehne und Konqueror verwende. Firefox entwickelt sich in eine Richtung, die ich für einen quelloffenen Browser nicht gut heißen kann. Insbesondere die IceWeasel Geschichte ist für mich ein Grund diesen Browser nicht zu verwenden.

Ich halte sehr viel von der WebKit Engine und hätte gerne einen darauf aufbauenden Browser. Leider befindet sich der WebKit KPart für Konqueror noch in Entwicklung, wird jedoch im Rahmen eines Google Summer of Code Projekts vorangebracht.

Ein neuer wirklich schneller und freier Browser könnte noch einmal richtig Belebung in den Browser Markt bringen. Mögliche Unterstützer für so einen Qt/WebKit Browser gibt es natürlich genügend: Nokia (Besitzer von Trolltech) und Apple (Initiatoren des WebKit Projekts) zum Beispiel.

Natürlich geht das Ganze nicht ohne Screenshot:

Man sieht sehr schön, dass dieser Browser sich in die Oberfläche integriert und kein Fremdkörper ist.

Mehr Infos findet man auch in diesem Blog Eintrag: Arora, a WebKit browser in Qt

Ich höre zur Zeit die Vorlesung Computergraphik II, in der nun Shader programmiert werden. Heute habe ich eine beeindruckende Übungsaufgabe gelöst. Letzte Woche hatten wir das Gouraud Shading als Vertex-Shader implementiert. Also für jeden Vertex wird die Farbe berechnet abhängig von der Lichtquelle. Dies bezeichnet man auch als “Per-Vertex-Lighting”.

Nun sollten wir das Modell erweitern. Die Berechnung der Farbe sollte nicht mehr pro Vertex, sondern pro Pixel berechnet werden. Es sollte das Phong Shading implementiert werden. Dies ist natürlich bedeutend aufwändiger. Aber das Ergebnis rechtfertigt den Aufwand:

Links sehen wir das Gouraud-Shading, rechts das Phong-Shading. Wie man erkennt sind die Hightlights auf den Objekten bedeutend genauer im Phong-Shading. Auch die grüne Grundfläche wird im Gouraud-Shading praktisch überhaupt nicht beleuchtet.

Noch eindrucksvoller kann man das Ganze in diesem Vergleich erkennen:

Das Highlight am Rand sieht im Phong-Shading viel natürlicher aus.

Nun diese Aufgabe zeigt, dass man mit relativ wenig Aufwand die Bildqualität doch massiv verbessern kann und dass es sich durchaus lohnt in die Grafik zu investieren.

Wie Heise heute berichtete wird der Sender ProSieben erneut ein Kopierschutzsignal in sein digitales Fernsehprogramm einfließen lassen. Es wird also nicht möglich sein mit einem digitalen Recoder eine Sendung aufzuzeichnen und später anzusehen. Daher entfällt die Möglichkeit mittels Timeshift die Werbung zu überspringen. Aus Sicht des Senders sicherlich verständlich, schließlich basiert das Geschäftsmodell auf der Werbung. Ja man könnte sogar sagen, dass jede werbefreie Sendeminute dem Unternehmen Verlust einbringt.

Was mich eher stört ist die Tatsache, dass in die Festplattenrecorder ein Antifeature eingebaut wurde. Ein Feature, dass dem Anwender keinen Nutzen sondern einen Nachteil bringt. Schaut man über dasselbe Gerät das Fernsehsignal direkt an, so funktioniert dies einwandfrei. Es sollte ja nun kein Problem sein das digitale Signal auf eine Festplatte zu speichern und erneut abzuspielen. Nein dafür gibt es das Antifeature. Die Hersteller haben extra etwas eingebaut, damit, wenn der Sender ein Kopierschutzsignal mitsendet, die Aufzeichnung praktisch zerstört wird. Wie bei allen sogenannten Digital Restriction Management Lösungen frage ich mich warum der Verbraucher dies akzeptiert. Jedem Laien muss doch klar sein, dass wenn man das Signal empfangen und anschauen kann, man es auch speichern können muss. Warum rufen nicht die Zuschauer bei ProSieben an und beschweren sich?

Tja ich bin von dem Antifeature nicht betroffen. Der Festplattenrecoder, den ich einsetze, ist ein VDR. Eine Quelloffene Lösung, in der – selbst wenn jemand ein Antifeature implementieren würde – solche Nutzergängelungen nicht überleben können. Eine Lösung, die noch viel mehr kann als alle verfügbaren Festplattenrecorder. Nicht nur, dass sich diese Software nicht für das Antifeature interessiert, nein es schneidet mir sogar die Werbung automatisch raus, so dass man sie einfach überspringen kann. Mit wenigen Tastendrücken, wird aus der Aufzeichnung eine DVD erstellt und direkt gebrannt. Was will man mehr? Ach ja: live streaming. Aufzeichnen und gleichzeitig anderes Programm anschauen. DVDs abspielen, MP3 hören, etc etc.

Leute überlistet doch einfach die “Content Mafia”. Verwendet Quelloffene Lösungen und ihr könnt nicht mehr gegängelt werden. Denn Quelloffenheit bedeutet fasst immer auch Freiheit. Freiheit die Software dafür einzusetzen, wofür man sie einsetzen will. Die Freiheit fehlende Features zu implementieren oder Antifeatures zu entfernen. Die Freiheit die Software weiterzugeben.

In diesem Artikel möchte ich mal ein kleines How-To schreiben wie ich meine Festplatte über einen Schlüssel auf einem USB-Key während des Bootens entschlüssele. Den Schlüssel für die verschlüsselte Festplatte auf einem USB-Key zu haben hat natürlich Vor- und Nachteile. Natürlich ist es eine Gefährdung für die Sicherheit, da jeder, der an den Stick drankommt auch an den Schlüssel kommt. Wenn man es schafft diese Gefahr zu reduzieren, bietet der Schlüssel einige Vorteile in der Bequemlichkeit. Man muss kein Passwort eintippen und die Festplatte wird “automatisch” entsperrt. Außerdem kommt man über einen Hardware-Keylogger nicht an das Passwort heran (jedoch ist das eher theoretischer Natur).

Ich setze nun folgendes Voraus: Es ist bereits eine verschlüsselte Partition über Cryptsetup angelegt und einer der Keyslots ist mit einem in einer Datei gespeicherten Schlüssel gefüllt. Außerdem ist der Boot-Vorgang so eingerichtet, dass von einer verschlüsselten Root-Partition gestartet wird.

Nun sollte man als erstes den USB-Stick als ext2 formatieren. Das hat zwei Vorteile: 1. man braucht keine Treiber für fat in die initrd integrieren. 2. sollte jemand mal aus Versehen an den Stick kommen, funktioniert er nicht unter Windows 😉
An der Stelle könnte man sich auch gleich die UUID des USB-Keys ausgeben lassen.

So nun kommen wir zum Kernstück des ganzen Vorhabens. Wir schreiben ein Skript welches das Passwort aus einer Datei auf dem USB-Stick liest und Cryptsetup zuführt. Cryptsetup unterstützt einen solchen Mode: es kann ein Skript angegeben werden, welches das Passwort zufüttert. Dabei ist es wichtig, dass JEDE Ausgabe des Skripts an Cryptsetup weitergegeben wird. Deshalb muss man alle Ausgaben auf stderr umleiten.
Mein Skript:

#!/bin/sh
modprobe usb-storage 1>&2
sleep 5
mkdir /usb 1>2&
mount -t ext2 /dev/disk/by-uuid/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx /usb 1>2&
sleep 5
cat /usb/root.key
umount /usb 1>2&

Wir sehen, dass Skript lädt als erstes das Treiber-Modul für USB-Sticks. Danach geben wir über den sleep dem System Zeit den Stick zu erkennen. Nun erzeugen wir den Mountpoint und binden den Stick ein. Erneut geben wir dem System etwas Zeit (hier kann man natürlich etwas herumspielen und die Zeit verkürzen). Nun geben wir einfach den Inhalt des gespeicherten Schlüssels aus und unmounten den Stick wieder. Beim Starten wird uns das ganze dann durch eine Success-Meldung angezeigt. An dieser Stelle kann man den Stick auch ohne Probleme wieder abziehen.

Nun müssen wir noch dem Cryptsetup mitteilen, dass wir ein Skript verwenden wollen. Dazu bearbeiten wir /etc/crypttab:

# target name|source device|key file|options
root /dev/vg1/vol1 none luks,retry=1,cipher=aes-cbc-essiv:sha256,keyscript=/path/to/keyscript

Wir sehen, dass entscheidende ist, dass bei “key file” “none” angegeben ist und bei den Optionen ein “keyscript=/path/to/keyscript” hinzukommt. Wenn man nun eine neue initrd erstellt, wird das Skript mit eingearbeitet.

Nun fehlt noch eins: die initrd braucht auch sämtliche Module um den USB-Stick überhaupt einbinden zu können. Sonst hat man ein Henne-Ei Problem. Der Treiber für den USB-Stick liegt im verschlüsselten System und um das System zu entschlüsseln, braucht man den Treiber. Dazu bearbeitet man die Datei /etc/initramfs-tools/modules. Hier müssen alle Module aufgelistet werden, die man braucht um den USB-Stick einzubinden. Da ich jetzt nicht genau weiß, welche es zwingen sind, gib ich mal meine komplette Datei an:

aes-x86_64
dm-crypt
dm-mod
sha256
sd_mod
usb_storage
usb-storage
ehci_hcd
ohci_hcd


Wenn ich jetzt nichts wichtiges vergessen habe, sollte man nun die initrd neue erzeugen können. Dies macht man über:
update-initramfs -u
Wichtig: erst mal nur die initrd für den aktuellen Kernel bearbeiten. Falls etwas nicht klappt, möchte man ja zumindest noch mit einem alten Kernel ein startfähiges System haben 😉

Nun ist der Zeitpunkt das ganze auszuprobieren. Reboot 🙂

… wenn man Student bei Google Summer of Code ist?

Das Postfach explodiert 😉

Ich hab nicht schlecht gestaunt, als ich heute morgen 300 ungelesene und unsortierte Mails in meinem Postfach entdeckt hatte. Es existiert eine Mailinglist, in der sich jeder Student vorstellen soll. Tja auf Grund von Zeitverschiebung konnte ich das nicht rechtzeitig reduzieren. Ich erwarte nun noch weitere 400 Mails.