Skip to content

OpenSource und Sicherheit

^ v M ><
Neulich hatte ich eine Diskussion über Open Source, Closed Source und Sicherheit. Mein Standpunkt war, dass ich mir sicher nicht proprietäre Software wie Dropbox oder Wuala installieren möchte. Natürlich ist Sicherheit hier mit ein Argument. Allerdings nicht nur die Sicherheit davor, dass kein Schadcode in der Software enthalten ist. Grad bei grösseren OpenSource-Projekten kann auch das nicht zu 100% ausgeschlossen werden. Grad die gewaltigen Codemengen, welche einige Firmen in Form von Treibern beitragen, kann kaum sinnvoll extern reviewed werden, da für ein komplettes Verständnis auch die Hardware-Spezifikation bekannt sein muss.

Es geht mir eher um eine andere Form von Sicherheit: Die Sicherheit, dass ich die Software auch morgen noch einsetzen kann. Denn proprietäre Software hat hier schon immer zu Problemen geführt. Entweder ist der Hersteller überhaupt nicht (mehr) willig, gewisse Plattformen zu unterstützen, oder er ist bei der Unterstützung neuer Plattformen einfach viel zu langsam. Letztendlich kann ich 90% allen Ärgers, den ich unter Linux je hatte, auf das 1% proprietäre Software schieben, den ich im Einsatz habe oder hatte.

Hier nur mal ein paar Beispiele aus meiner Erfahrung:

  • VMWare Server (vor vielen Jahren): Nach dem Kernelupdate (Bugfix-Release) lassen sich die Module ums verrecken nicht mehr kompilieren.

  • Adobe Flash Player: Erinnert sich noch wer an die Zeiten, als 64bit unter x86 noch neumodischer Schnickschnack war? Da hatte man die Wahl, entweder einen 32bit-Browser ins System reinzuwürgen, den semiproprietären nspluginswrapper zu verwenden, um das 32bit-Flashplugin unter 64bit-Browsern zu nutzen, oder aber eine der nicht funktionierenden freien Flash-Alternativen zu installieren. Oder einfach alternativ jahrelang auf Flash verzichten. Oh, Adobe hat ja neulich auch beschlossen, dass Flash für amd64 in Zukunft gar nicht mehr weiterentwickelt wird.

  • Skype: Bis es endlich die offiziellen "64bit"-Pakete gab, konnte man die Software nur unter kompletter Verhunzung der Paketverwaltung ins System würgen. Und dann noch dieses neumodische Audiotreiberzeugs namens ALSA, lass mal noch ein paar Jahre beim obsoleten OSS bleiben... aber hey, das grauenhafte PulsAudio-Zeugs, das ist so schlecht, das unterstützen wir sofort und exklusiv.

  • PowerVR Grafiktreiber (für die gute, alte KyroII): nett, dieses Kernel 2.6 Zeugs. Aber einen (instabilen) Treiber gibt's nur für Kernel 2.4. Wer's neuer will, der kann ja den VESA-Treiber nehmen. Doku für die freie Treiberentwicklung? bwahahaha, der war gut!

  • nVidia-Grafiktreiber: Trotz Linus' Stinkefinger ja die Vorzeigefirma unter den proprietären Treiberentwicklern: Oh, alte Hardware wird nicht mehr unterstützt. Ausser mit alten Treiberversionen, die keine neuen Kernel unterstützen. Oh, und dieses neumodische KMS-Zeugs mit älterer Hardware... nun, hübsche Konsole, so mit extremer Verzerrung und nicht mehr leserbaren Bootmeldungen...

  • AMD-Grafiktreiber: Lass mal den neusten AMD-Treiber auf einem 6 Jahre alten Kernel kompilieren... oh geht nicht, Kernel ist zu neu... Dazu hab ich mich ja schon mehrfach ausgelassen. Ganz davon abgesehen, dass die letzte Treiberversion für meine Hardware der 12.04 ist. Da kann ich nur hoffen, dass bis ich den Umstieg auf Debian 8 ins Auge fasse, der freie radeon-Treiber was taugt. Grad im Bereich Multimonitor.

  • Druckertreiber für non-Postscript Drucker: Funktionieren nur mit sehr exotischen Distributionen, haben komische Abhängigkeiten, und natürlich nur für 32bit x86 Systeme.

  • Wine und Windows-Spiele: Guter Witz. Ich hab da kaum je was zum laufen gekriegt. Auch wenn Wine der Meinung war, das Spiel hätte Platin-Unterstützung (d.h. perfekt)


Aber auch Hardware ist mühsam, sobald sie nicht über ausreichend freie Dokumentation verfügt:

  • Noch einmal AMD und nVidia: Die freien Treiber waren jahrelang gar nicht brauchbar, unterdessen geht wenigstens so langsam mal das grundlegende.

  • Windows-Only GDI Drucker: aaaaaaaaaargh!

  • Nokia-Telefone: Viel Spass beim Zugriff mit Gnokii. Vielleicht geht es. Wahrscheinlich nicht.

  • Pogoplug: Die Pro-Platine (auch im spottbilligen Pogoplug Pink verwendet) verwendet ein proprietäres SoC, in dessen Dokumentation nur ein freier Entwickler unter NDA Einsicht hat. Die Konsequenz: Das Gerät läuft nur mit Arch Linux ARM und uralt-Kernel 2.6.31. Und die wichtigsten Treiber für viele USB-Geräte fehlen darin.



A propos Pogoplug: Der sowie z.B. der Raspberry Pi benutzen die ARM-Architektur. Über die Verwendung von Skype, Flash oder Dropbox nachzudenken, ist absolut müssig.

Debian schlank halten

^ v M ><
Debian hat mich grad neulich 2x erschreckt. Zuerst hat es mir eine gewaltige Liste an sinnlosen Abhängigkeiten zu einem Paket installieren wollen. Danach hat mein Debian Testing/Wheezy beim Laden der Paketlisten Ewigkeiten rumgeladen und rumgerödelt. Das will ich ihm abgewöhnen. Zeit für eine FDH-Magerkur!

Dazu wird eine Datei /etc/apt/apt.conf.d/00lean angelegt (Name ist eigentlich egal) und mit folgendem Inhalt bestückt (nicht egal):
APT::Install-Recommends "0";
APT::Install-Suggests "0";
Acquire::Languages { "environment"; "en"; "de"; };

Leider lädt Debian damit bei der Paketlistenaktualisierung immer noch alle Übersetzungen runter. Daher muss erst mal /var/lib/apt/lists aufgeräumt werden. Grundsätzlich genügt es wohl, alle *_i18n_Translation-* Dateien in dem Verzeichnis zu löschen. Ich hab einen etwas sichereren und leicht bandbreitenbelastenderen Weg genommen und grad das ganze lists-Verzeichnis umbenannt und neu erstellt (falls was schief gegangen wäre, hätte ich das immer noch rückgängig machen können):
cd /var/lib/apt/
mv lists lists.old
mkdir lists
aptitude update

Nach erfolgreichem Update habe ich das Verzeichnis lists.old gelöscht.

Gnokii und Phonet

^ v M ><
Die neueren Versionen von Gnokii (0.6.30 und neuer) bieten eine neue Verbindungsoption zu s40-Telefonen: Den Phonet-Treiber. Leider ist die Dokumentation im Gnokii-Wiki dazu sehr spärlich und auch sonst weiss das Internet nicht viel dazu. Jedoch ist er relativ gut im Source-Tarball des Gnokii-Projekts beschrieben. Die Source brauchte ich sowieso, um das aktuelle Gnokii für mein Debian Squeeze zu kompilieren.

Die Idee hinter diesem Treiber ist, dass die Nokia-Telefone sich als USB-Modem einbinden lassen und eine virtuelle Netzwerkschnittstelle erstellt wird. Um diese ansprechen zu können, müsste gnokii im Prinzip mit root-Rechten ausgeführt werden. Man kann das jedoch umgehen. Einerseits muss man der gnokii-Applikation etwas mehr Capabilities zugestehen, andererseits muss man dafür sorgen, dass die Schnittstelle automatisch gestartet wird, wenn man das Telefon an den PC anschliesst:

Gnokii Capabilities setzen (als root):
setcap cap_sys_admin,cap_net_raw=+ep $(which gnokii)
setcap cap_sys_admin,cap_net_raw=+ep $(which xgnokii)

Um die virtuelle usbpn-Schnittstelle automatisch zu starten, werden unter Debian/Ubuntu folgende drei Zeilen in der /etc/network/interfaces benötigt:
allow-hotplug usbpn0
iface usbpn0 inet manual
up ifconfig usbpn0 up

Nun muss noch die gnokii-Konfigurationsdatei unter ~/.config/gnokii/config erstellt werden:
[global]
port = usbpn0
connection = phonet
model = series40
[connect_script]
TELEPHONE = 12345678
[disconnect_script]
[logging]
[flags]


Leider hat mich das nicht ernsthaft weiter gebracht. Das Billigst-Telefon (Nokia C1) lässt weiterhin keinen Zugriff auf die SMS-Inbox zu. Telefonbuch auslesen und bearbeiten sowie zumindest SMS versenden klappt sowohl über den AT- wie auch den Phonet-Treiber problemlos.

Nachtrag vom 24.10.: mit Debian Wheezy lässt sich zumindest die Ordnerliste anzeigen, jedoch wird jeder Ordner als leer angezeigt. Das Speichern von SMS funktioniert. SMS lesen scheint aber nach wie vor nicht zu klappen.