Category: ubuntuusers

Da ja aktuell im Planet von ubuntuusers einige Posts zum Betriebssystemtest der Chip sich sammeln, möchte ich auch noch meinen Senf dazu abgeben.

Was mich am meisten stört, ist dass von Kubuntu eine Alpha Version verwendet wurde. Ist im Artikel nicht erwähnt kann man aber leicht am Screenshot erkennen. So ist klar ein KDE 4.3 erkennbar. Dies gibt es erst in Karmic oder über Backports für Jaunty. Da man aber hervorhob, dass es eine neue KDE Version in dem Kubuntu gibt, gehe ich davon aus, dass es Karmic ist. Die Screenshots erlauben übrigens eine ziemlich genaue Datierung. Im Panel fehlt das “Message Indicator” Plasmoid welches in Alpha 4 eingefügt wurde – also vor dem 13. August. Eine Alpha Version in einem so frühen Stadium zu testen, nun ja, kann sich jeder selbst sein Bild von machen. [Update]Zumindest die beigelegte Live-CD ist ein Jaunty mit 4.3 über Backport Quellen und weiteren Fremdquellen. Was nun zum Einsatz kam für den Test, kann ich nicht sagen. Eine Backport Quelle wäre jedoch noch fahrlässiger als eine Alpha.[/Update]

Was man an den Screenshots auch schön erkennen kann, ist, dass Compositing nicht aktiviert ist. In dem Abschnitt “Fazit” steht “die fehlenden Treiber bei Kubuntu sind klare Nachteile”. Da sehe ich doch einen Zusammenhang: fehlende Treiber und kein Compositing. Bei Jaunty wäre mir keine moderne Grafikkarte bekannt, die keinen Treiber hat. Wenn es eine Ati oder NVIDIA Karte ist, würde man im Systemabschnitt der Kontrollleise einen Hinweis sehen, dass Treiber verfügbar sind. Wie man im Screenshot erkennen kann, ist dieses Symbol nicht zu sehen und es gibt auch keine ausgeblendeten Symbole. Dies bestätigt meinen Verdacht der verwendeten Alpha Version.

Der Screenshot verrät viel mehr als man denkt. So sieht man, dass noch die KDE 3 Version von K3B verwendet wird, im kommenden Karmic ist aber die KDE 4 Variante. Selbst das Icon ist noch die KDE 3 Variante, in Jaunty mit Backports hat man die Oxygen Variante. [Update]Es reicht nicht nur nach dem Symbol in KRunner zu schauen – in Jaunty wird auch das KDE 3 Icon angezeigt.[/Update] Der Screenshot wurde am 09.09. aufgenommen. Interssant ist das Dolphin Fenster, dort sieht man einen Geändert Zeitstempel welcher 3 Minuten vor der aktuellen Zeit liegt. Die Kubuntu CD ist eingehängt, eine vorhandene Festplatte jedoch nicht. Wenn in der Titelleiste nicht “chipuser” stehen würde, würde ich behaupten das ist ein Screenshot aus einer Live-CD. Jedoch macht mir “Wir haben für Sie eine angepasste CHIP-Edition von Kubuntu auf die Heft-DVD gepackt” in dem Zusammenhang Angst. Eine Live-CD zu remastern und den kubuntu User in chipuser umzubenennen ist nicht wirklich schwer, daher gehe ich davon aus, dass es eine Live-CD ist.

Die Bildunterschrift ist natürlich der absolute Hammer: “Eine Übersichtsfunktion für offene Fenster gibt es nicht”. Das ist eine dreiste Lüge. Hätten sie eine stabile Version verwendet, hätten sie auch die Übersichtsfunktion gesehen. Ganz toll, dass man gerade zwei Funktionen der Konkurrenz gezeigt hat, die wir beide unterstützen.

Wäre ich Autor der entsprechenden Effekte Present Windows oder Taskbar Thumbnails, dann wäre der Presserat informiert und die Chip dürfte eine Gegendarstellung veröffentlichen. Leider bin ich aber von diesen Funktionen nicht der Autor. Dennoch wurde eine Gegendarstellung im Forum erarbeitet und eine Unterschriftenaktion gestartet. Wer sich an dieser – aus meiner Sicht sinnreichen und korrekten – Aktion beteiligen möchte, kann sich im Forum zuschalten oder sich wohl auch gerne bei AlphaX2 melden.

=-=-=-=-=
Powered by Blogilo

Dies ist ein Folgeartikel zu meinem gestrigen Artikel, dass das Verschleiern von E-Mail Adressen nicht funktioniert und nutzlos ist. Viele Kommentare zu dem Artikel sagen, dass sie meinen dass die Verschleierung doch hilft, weil sie der Meinung sind, dass Bots nicht an den verschleierten Adressen interessiert sind.

Um noch mal zusammenzufassen: wir nutzen Verschleierung um zu verhindern, dass Spam Bots E-Mail-Adressen ernten. Wir verschleiern auf eine Art, so dass

• Menschen die E-Mail-Adresse lesen können

• Computer die E-Mail-Adresse nicht lesen können

Das klingt nach einem CAPTCHA. Falls ihr die “was erlaubt ist und was nicht” zu CAPTCHAs nicht kennt, empfehle ich die Lektüre der Informationen auf captcha.net. Eine der wichtigsten Fakten ist, dass man kein CAPTCHA verwenden sollte, dass nicht mehr funktioniert, sobald alle es benutzen. Also in dem Augenblick wenn die Bots das CAPTCHA unterstützen.

Kommen wir zurück zu den verschleierten E-Mail-Adressen.Ich denke wir können uns darauf einigen, dass Verschleierung vom Konzept her nicht funktioniert. Ich denke wir können es mit Kryptographie vergleichen: obwohl es noch keinen wirklichen Anwendungsfall zum Angriff auf MD5 gibt, würde wohl niemand MD5 noch verwenden um wichtige Dokumente digital zu signieren.

So bald die Harvester anfangen nach verschleierten E-Mail-Adressen zu suchen, werden sie sie finden. Wenn man heute eine E-Mail-Adresse im Web verschleiert und in fünf Jahren die Harvester anfangen Adressen zu entschleiern, werden sie die Adresse finden. Pech gehabt.

Also anstatt ein nicht funktionierendes CAPTCHA wie die Verschleierung zu verwenden, sollte man ein sicheres CAPTCHA wie den Mailhide Dienst von reCAPTCHA verwenden. Es existieren Plugins für viele Programmiersprachen und es könnte verwendet werden um z.B. automatisch alle E-Mail-Adressen in Mailman Archiven durch einen Link zum CAPTCHA zu ersetzen. Dies sieht wie folgt aus: jsm…@example.com

Das Lösen von reCAPTCHAs ist meistens bedeutend leichter als von normalen CAPTCHAs, weil man ein komplettes Wort lösen muss und es ist wahrscheinlich auch einfacher zu lösen als eine komische Verschleierungsregel. Und es hilft Bücher und Zeitungen zu digitalisieren und am Ende bekommt man einen anklickbaren E-Mail-Link.

Ich weiß, dass ihr jetzt sagt “reCAPTCHA gehört zu Google und Google ist böse. Ich möchte Google nicht meine E-Mail-Adresse geben”. Falls ihr das denkt, denkt nach. Denkt ihr wirklich, dass der größte Web Harvester der Welt die einfache Verschleierung nicht brechen kann? Habt ihr noch nie eine E-Mail an eine gmail/googlemail Adresse gesendet? Ihr nutzt kein Jabber mit Google Talk Nutzern? Ihr habt keinen Google Account? Denkt ihr wirklich Google hat nicht schon längst eure E-Mail-Adresse? Und wenn ihr wirklich reCAPTCHA nicht vertraut, dann kann man immer noch scr.im verwenden um eine CAPTCHA gesicherte Kurzurl zu erhalten. Aber ich empfehle die Verwendung eines gut getesteten CAPTCHA Systems.

Zusammenfassend: Ich stimme zu, dass man die E-Mail-Adressen auf Webseiten schützen soll. Aber bitte macht euch den Gefallen und macht es richtig. Verschleierung ist gebrochen und es ist nur eine Frage der Zeit, bis die Harvester anfangen verschleierte Mails abzugrasen. Es gibt Dienste welche ein sicheres CAPTCHA zum Schutz der E-Mail-Adressen anbieten. Bitte diese verwenden. Und nein dies ist keine Werbekampagne für reCAPTCHA – es ist einfach nur der beste CAPTCHA Dienst den ich kenne. Falls jemand einen besseren kennt, der sicherer ist und nicht Google gehört: bitte Kommentar hinterlassen – ich bin interessiert.

Viele Leute verschleiern ihre E-Mail-Adresse auf Webseiten in der Hoffnung, dass Bots diese nicht aus der Webseite extrahieren können. Das könnte wie folgt aussehen:

email [AT] example [dot] tld

Diese Vorgehensweise wird zum Beispiel von Mailmans Archiv Pipermail und der MARC E-Mail Schnittstelle, welche von KDE Mailinglisten verwendet wird, angewendet. Manche Leute bitten sogar darum “E-Mail-Adressen nicht unverschleiert im E-Mail Text zu zitieren”.

Ist das Verschleiern von E-Mail-Adressen überhaupt sinnvoll? Gewinnt man dadurch mehr Sicherheit?

Die Antwort ist Nein. Die Verschleierung ist eine CAPTCHA Variante (Completely Automated Public Turing test to tell Computers and Humans Apart). Ein CAPTCHA erfordert, dass ein Computer das Künstliche Intelligenz Problem nicht lösen kann, wenn er Zugriff auf alle Informationen hat, welche benötigt werden um den Test zu erstellen. Gestern hab ich versucht zu beweisen, dass diese Art von CAPTCHAs geknackt ist und hab dazu eine kleine Anwendung geschrieben, welche die E-Mail-Adressen von einem öffentlichen Pipermail Archiv extrahiert. Die Anwendung besteht aus weniger als 300 Zeilen Code und kann automatisch alle E-Mails für einen gegebenen Monat und Jahr herunterladen und die Sender Adresse extrahieren durch das Rausziehen aller a Elemente der online abrufbaren E-Mail. Auf diese Elemente wird ein regulärer Ausdruck angewendet um die E-Mail Adresse zu erhalten. Ich wollte eigentlich nur etwa eine halbe Stunde daran arbeiten, am Ende hab ich dafür Qt 4.6 kompiliert, weil ich das neue QWebElement benötigte 😉 Falls jemand Interesse am Quellcode hat, kann ich ein Repository auf gitorious anlegen.

Das folgende Bild zeigt das Ergebnis eines “Angriffs” auf das plasma-devel Archiv. Aus Datenschutzgründen hab ich den Nutzerteil der E-Mail-Adressen unlesbar gemacht.

Ich bin der Meinung, dass keine verlässliche Möglichkeit existiert E-Mail-Adressen nur durch Text zu verschleiern. Wenn es einen Algorithmus zum Verschleiern gibt, dann gibt es auch einen regulären Ausdruck um die Verschleierung aufzuheben. Die einzige Möglichkeit eine E-Mail-Adresse zu schützen, ist sie nirgends anzugeben wo ein Bot sie aufsammeln könnte. Dazu könnte man sie durch ein “echtes” CAPTCHA ersetzen, welches die E-Mail-Adresse nach dem Lösen preisgibt. Für Webseiten existiert zum Beispiel die Mailhide API von reCAPTCHA. Für Mailinglisten ist das ganze komplett nutzlos, da die Adresse sowieso unverschleiert in den E-Mail Headern steht. Anstatt Webseiten zu parsen könnten Bots auch einfach die Mailingliste abonnieren.

Also bitte hört auf die E-Mail Adressen zu verschleiern. Es ist nutzlos und man kann nicht mehr auf E-Mail Links klicken. Stattdessen muss der Leser ein nutzloses CAPTCHA lösen.

Ich hab heute meinen Rechner einmal komplett dicht gemacht und möchte mal vorstellen, wie man so etwas machen kann. Die Anforderungen waren: es soll möglich sein eine statische HTML Seite zu benutzen und mehrere Videos anzuschauen. Es soll unmöglich sein andere Anwendungen zu starten oder irgendwelche Dateien zu öffnen. KDE bietet mit dem KIOSK Framework im Prinzip alles was man braucht.

Ich habe natürlich einen extra Nutzer welcher mein Home Verzeichnis nicht einsehen darf. Damit sind schon mal sämtliche Dateien geschützt.

Die Idee war nun Konqueror entsprechend zurecht zu manipulieren. Moment Konqueror? Einen Dateimanager so verändern, dass man keinerlei private Daten sehen kann? Ja KDE macht’s möglich 😉 Über eine Fensterspezifische Regel wird Konqueror in den Vollbildmodus gezwungen. Da es eine Regel ist, kann man diesen auch nicht mehr beenden. Globale Shortcuts werden auch geblockt, somit ist es nicht möglich über Alt+F2 neue Anwendungen zu starten oder über Alt+F4 oder Strg+Alt+Esc Konqueror zu beenden. Zusätzlich werden alle wichtigen Shortcuts deaktiviert. Also zum Beispiel Strg+Q zum Beenden. Damit ist es über die Tastenkürzel nicht mehr möglich aus Konqueror rauszuwechseln.

Nun muss natürlich noch mehr bearbeitet werden, zum Beispiel die Werkzeugleisten. Hier kann man die Adressbar entfernen und somit das Wechseln in ein Verzeichnis verhindern und plötzlich ist Konqueror kein Dateimanager mehr.

Aber es ist ja immer noch möglich die Konfiguration wieder aufzurufen und alles rückgängig zu machen. Hier kommt nun KIOSK zum Einsatz. Man muss nur eine systemweite kdeglobals Datei bearbeiten und kann dann einige Restriktionen definieren. Z.B. das Starten der Konsole unterdrücken oder das Konfigurieren der Shortcuts verhindern. Damit sind die Werkzeugleisten und Shortcuts abgesichert.

Aber über das Menü kann man ja immer noch Konqueror beenden. Schlecht, also muss man auch noch mal dran. Zum Glück kann man die Menüs über XML Dateien verändern. Also einmal die ~/.kde/share/apps/konqueror/konqueror.rc anfassen und sämtliche Einträge entfernen und TATA es gibt kein Datei Menü mehr. Konqueror lässt sich nicht mehr beenden.

Last but not least muss man noch ein bißchen weiter schauen, da Konqueror auch weitere Programme startet. So zum Beispiel konnte ich den Quellcode zeigen Menüpunkt nicht entfernen. Also noch mal eine Regel für KWrite anlegen und globale Shortcuts definieren. Anwendung selbst ist auch über KIOSK sicher. Gleiches für den Video Player.

Damit ist das Ziel erreicht: Konqueror ist auf den minimalen Bereich eingeschränkt, welcher über die Startseite vorgegeben ist. Es lassen sich die Videos öffnen, aber keine anderen als die vorgegebenen.

Sicherheitshalber sollte man noch Plasma beenden, damit nicht plötzlich der KMenü Button in den Vordergrund kommt. Wenn man wirklich nur eine Anwendung braucht, könnte man auch noch den Fenstermanager ausschalten. Aber da der Videoplayer gestartet werden soll, geht das in diesem Fall nicht.

Das war das erste Mal, dass ich KIOSK eingesetzt habe und die Mächtigkeit ist einfach gigantisch. Mir war durchaus bewusst, dass KDE ein gutes Lockdown System hat, hatte es aber noch nie getestet. Und mit dem Wissen, dass das ganze in der kommenden Version weiter ausgebaut wird, kann man wirklich sagen, dass KDE eine gute Grundlage für den Einsatz in Unternehmen hat um z.B. ein Corporate Design durchzudrücken äh einzusetzen.

Heute ist der Opt Out Day. Die Meldebehörden haben das Recht persönliche Daten weiterzugeben, z.B. an Parteien für Wahlwerbung oder sogar für Direktwerbung. Diesem kann man natürlich Widersprechen und wem informationelle Selbstbestimmung wichtig ist, sollte dies auch machen. Dafür wurde heute der Opt Out Day angesetzt. Eigentlich sollte die Weitergabe ja ein Opt In sein, aber lieber ein Opt Out als gar keine Möglichkeit sich dagegen zu wehren. In den Einwohnermeldeämtern gibt es Formulare, zum Teil sogar online verfügbar. Also ausdrucken, unterschreiben und heute beim Meldeamt vorbeibringen oder wenn man keine Zeit hat, die 55 Cent für mehr informationelle Selbstbestimmung investieren.

Für Mannheimer Leser: heute um 16 Uhr findet eine gemeinsame Übergabe der unterschriebenen Forumulare vor dem Einwohnermeldeamt in K7 statt.

Auf Grund der neuen Richtlinie des ubuntuusers Wikiteams zu PPAs möchte ich einfach mal ein Beispiel geben, wie leicht es sein kann durch ein PPA sein System in einen Zustand zu bringen, dass man nicht auf die neuste Version aktualisieren kann.

Als Beispiel nehme ich die KDE Fensterdekoration Aurorae. Sie ist für KDE 4.3 und es gibt noch keine Pakete für Jaunty. Es befindet sich in den Paketquellen für Karmic als kwin-style-aurorae und in Karmic+1 wird dieses Paket entfernt werden, da Aurorae Bestandteil von KWin in KDE 4.4 ist. Das ist wichtig im Verlaufe dieses Blogposts zu erinnern.

Angenommen ich hätte mit der Veroffentlichung von Aurorae auch ein Paket gebaut und in ein PPA gestellt. Zu dem Zeitpunkt hätte es noch kein Paket von Kubuntu gegeben und ich hätte mein Paket einfach mal aurorae genannt. Das Namensschema ist mir nicht bewusst. Ich hätte natürlich das PPA in den passenden Artikeln im ubuntuusers Wiki eingestellt. Ist ja nach den neuen Richtlinien abgedeckt, ich bin ja der Entwickler und weiß was ich tue.

Nun denke ich sollte das erste Problem schon erkennbar sein. Wenn ein Nutzer Karmic verwendet und die PPA Quelle freigeschaltet hat, dann hat er plötzlich zwei Pakete für die gleiche Software:

• aurorae
• kwin-style-aurorae

Diese Pakete enthalten exakt die gleiche Version und exakt die gleichen Dateien. Wenn man das Changelog mit den Maintainern entfernt, müsste – wenn ich korrekt gebaut habe – sogar die MD5 Summe übereinstimmen.

Mittlerweile existiert Karmic und ich biete die PPA Quelle nicht mehr an. Es befindet sich ja in den Paketquellen. Nun hab ich plötzlich einen schwerwiegenden Crash in der Dekoration festgestellt und behoben. Das ganze wird in trunk eingespielt und (weil wichtig) aktualisiere ich auch den tarball auf kde-look sowie informiere ich meine wichtigsten Downstreams (openSUSE und Kubuntu), damit sie neue Pakete bauen. An meine alte Paketquelle für Jaunty denke ich nicht mehr – ich bin unter Stress.

Das Problem dürfte recht erkennbar sein: wer das Paket aus den offiziellen Quellen installiert hat, bekommt automatisch das Update. Wer das Paket aus dem PPA hat, jedoch nicht. Bugs werden nicht mehr behoben.

Nun dreht sich das Rad der Zeit weiter. Weitere sechs Monate sind vergangen und das Upgrade auf Karmic+1 steht an. Aurorae wurde Ende Januar/Anfang Februar in KDE aufgenommen. Die Kubuntu Maintainer wissen das und passen ihre Abhängigkeiten entsprechend an. kwin-style-aurorae wird ein virtuelles Paket und kdebase-workspace hat die Abhängigkeiten so gesetzt, dass das Paket entfernt wurde. Ein Upgrade verursacht kein Problem. An Aurorae wurde seit dem ersten Paket jedoch kaum noch gearbeitet. Insbesondere heißen die Dateien noch gleich und werden an die gleichen Stellen wie zuvor installiert.

Nun gibt es immer noch User, die mein Paket aus der Zeit von Jaunty verwenden. Was wird passieren? Sie machen ihr Upgrade. Die Kubuntu Entwickler haben ihre Abhängigkeiten angepasst, von meinem komischen Paket was ich seit Monaten nicht mehr anbiete, wissen sie jedoch nichts oder denken nicht dran. kdebase-workspace wird also mein Paket nicht ersetzen. Nun wird das Upgrade durchgeführt. Irgendwann wird kdebase-workspace aktualisiert und schwups haben wir ein Problem. Das Paket enthält Dateien, die schon exisitieren! Nämlich die Dateien aus dem Paket aurorae. Das Upgrade schlägt fehl. kdebase-workspace ist nicht installiert. Der Anwender sieht den Fehler und installiert erst mal munter weiter. Passiert ja mal, dass ein Paket nicht funktioniert. Dann macht er den Neustart – wie aufgefordert. Er meldet sich an, der Splash Screen kommt, der Splash Screen geht und der Hintergrund ist schwarz. Aber warum? Nun ganz einfach: kdebase-workspace wurde nicht aktualisiert. Also kein Plasma, kein kwin – kein Desktop und kein Fenstermanager. Man kann auf dem System keine Anwendung aus der grafischen Oberfläche starten. Man kann keinen Browser aufmachen um im Forum nachzufragen wie das Problem behoben werden kann. Man hat für den Normalanwender ein zuerstörtes System.

Ich hoffe ich konnte mit diesem kleinen Beispiel ganz gut aufzeigen warum PPAs und Fremdquellen im Allgemeinen ein riesiges Problem beim Update darstellen können. Wer sicher sein will, nimmt entweder keine PPAs oder nur die von den Maintainern, da diese ihre Abhängigkeiten anpassen.