staging.inyokaproject.org

2021 Woche 49

12. Dezember 2021

  1. GrapheneOS – Warum kein anderes System?
  2. GrapheneOS – Viele Maßnahmen für die Sicherheit
  3. GrapheneOS – Installation und Einrichtung
  4. GrapheneOS – Eine Sammlung von F-Droid Apps
  5. GrapheneOS – Updates ohne Risiko

Die Installation von GrapheneOS ist auf einem Pixel-Gerät ohne Hacks und komische Handgriffe möglich. Von der komplizierten Anleitung sollte man sich nicht abschrecken lassen. Geht man sie Schritt für Schritt durch, kann man eigentlich keine Fehler machen. Eine Rückkehr zum Ursprungszustand ist immer möglich.

Es gibt einen Webinstaller und die Installation ist hervorragend bei GrapheneOS dokumentiert. Weil auf meinem Desktop kein Chromium bzw. ein Chromium-Fork installiert ist und Firefox nicht offiziell supportet wird, habe ich mich für die Installation auf der Kommandozeile entschieden. Für die Vollständigkeit der Serie möchte ich das hier kurz darstellen, empfehle aber bei entsprechenden Englischkenntnissen die GrapheneOS-Dokumentation.

Installation von GrapheneOS auf dem Pixel 6

OEM aktivieren

Zuerst muss man im Google Stock ROM die OEM Option aktivieren. Das war tatsächlich das erste und einzige Mal, das ich das originale Google-Betriebssystem des Pixel 6 starten musste – vom ersten Funktionstest direkt nach dem Kauf einmal abgesehen.

Das erfolgt in zwei Schritten:

  1. Einstellungen –> Über das Telefon –> Mehrfach die BuildNummer tippen bis die Entwickleroptionen freigeschaltet werden.
  2. Einstellungen –> System –> Entwickleroptionen –> Schalter bei OEM-Entsperrung umlegen

Danach kann man das Gerät erst mal wieder abschalten.

Image herunterladen und prüfen

Nun bezieht man die notwendigen Images von GrapheneOS und prüft diese mit signify. Das haben alle Distributionen in den Paketquellen. Bei Debian und allen Derivaten aufpassen, dass man das richtige Paket signify-openbsd nimmt und nicht das nutzlose und nicht gewartete signify.

Zuerst lädt man den öffentlichen Schlüssel von GrapheneOS herunter. Das kann man z. B. mit curl erledigen.

$ curl -O https://releases.grapheneos.org/factory.pub

Anschließend folgen das sogenannte Factory Image und die entsprechende Sig-Datei. Die URL ist das experimentelle Release vom 11.12.2021 und folglich den aktuellen Gegebenheiten anzupassen:

$ curl -O https://releases.grapheneos.org/oriole-factory-2021121117.zip
$ curl -O https://releases.grapheneos.org/oriole-factory-2021121117.zip.sig

Nun erfolgt die Prüfung, ob die Downloads korrekt sind. Auch hier sind die Dateinamen zukünftig anzupassen.

$ signify -Cqp factory.pub -x oriole-factory-2021121117.zip.sig && echo verified
verified

Das heruntergeladene Image kann man mit z. B. bsdtar entpacken.

$ bsdtar xvf oriole-factory-2021121117.zip

Fastboot installieren

Für die folgenden Schritte benötigt man fastboot und die android-udev Regeln. Viele Distributionen haben die Android-Tools in den Paketquellen. Nicht bei allen sind sie in den entsprechend aktuellen Versionen vorhanden. Die entsprechenden Warnhinweise bei GrapheneOS sollte man ernst nehmen und deshalb vorab prüfen, welche Version man installiert hat.

$ fastboot --version
fastboot version 31.0.3-android-tools
Installed as /usr/bin/fastboot

Zum Zeitpunkt des Verfassens dieses Beitrags 31.0.3 zulässig. Die in openSUSE Tumbleweed enthaltene Version reichte also aus. Ansonsten sind bei GrapheneOS Hinweise zu finden, wie man die offiziellen Android-Tools beziehen kann.

Bootloader öffnen und GrapheneOS installieren

Nun startet man das Smartphone mit gedrückter Lautstärke-runter Taste. Das Smartphone startet dadurch in die Bootloader-Oberfläche.

Nun verbindet man das Smartphone mittels Kabel mit dem PC und entsperrt den Bootloader mit folgendem Befehl:

$ fastboot flashing unlock

Nun wechselt man in das Verzeichnis mit dem Image:

$ cd oriole-factory-2021121117

Danach kann man die Installation beginnen

$ ./flash-all.sh

Die Installation läuft nun durch. Das Smartphone startet derweil mehrfach neu und wechselt unter anderem ins Bootloader Interface und Recovery-System. Hier sieht es teilweise so aus, als ob man als Anwender etwas machen könnte oder sollte. Einfach nichts tun und warten! Irgendwann endet der Prozess im Bootloader-Interface.

Hier nun den Bootloader wieder sperren, um den verifizierten Start wieder herzustellen und weitere Manipulationen am Gerät zu unterbinden.

$ fastboot flashing lock

Einrichtung nach der Installation

Nun kann man das Smartphone initial starten. Beim Start kommt ein Hinweis auf das alternative Betriebssystem. Hiervon nicht irritieren lassen, das ist normal und erscheint nur beim Stock Android von Google nicht. Anschließend wird man vom GrapheneOS Startscreen begrüßt. Nach dem ersten Start kommt die obligatorische Einrichtungsroutine von Android. Auf diese wird hier nicht näher eingegangen.

Zuerst sollte man die Erlaubnis zur OEM-Entsperrung in den Entwickleroptionen widerrufen. Dazu einfach wie oben die entsprechenden Einstellungen aufrufen und dort die Option deaktivieren.

Wie bereits in einem anderen Teil der Serie thematisiert, ist GrapheneOS sehr reduziert im Umfang. Wer hier mehr Komfort haben möchte, kann ggf. einen Blick auf CalxyOS werfen.

Standardmäßig sieht ein GrapheneOS-System so aus:

Selbst absolut puristische Anwender werden nicht umhin kommen einige Apps aus F-Droid zu beziehen.

Dazu in Einstellungen –> Apps –> Spezieller Zugriff –> Installieren unbekannter Apps für Vanadium erlauben. Dann mittels eben jenes Vanadium die Webseite von F-Droid aufrufen und den Store herunterladen und installieren.

Danach in jedem Fall die Berechtigung für Vanadium rückgängig machen und entsprechend für F-Droid erteilen.

Updates kommen nun für die nächsten Jahre einfach Over-The-Air (OTA).

Der Artikel GrapheneOS – Installation und Einrichtung erschien zuerst auf [Mer]Curius

Wer meinen Blog ein wenig liest und mich ein wenig kennt, weiß, dass ich aktuell relativ viel mit Kubernetes „herumspiele“. Siehe meinen Blogpost zum Homeserver-Setup in 2021.

Dieser Blogpost geht ein wenig darauf ein, warum ich die Zertifizierung „Certified Kubernetes Application Developer“ (CKAD) gemacht habe, wie ich mich darauf vorbereitet habe und warum das Drumherum um die Prüfung total nervig war.

Die CKAD-Zertifizierung ist die Zertifizierung, die sich eher an Entwickler richtet, während die „Certified Kubernetes Administrator“ Zertifizierung (CKA, ohne D) und „Certified Kubernetes Security Specialist“ Zertifizierung (CKS) sich eher an Administratoren richtet.

Der Spaß kostet mittlerweile $375 und findet Online statt. Es gibt immer allerdings immer wieder Angebote, wo es weniger kostet.

Warum eigentlich eine Zertifizierung?

Die allgemeine Frage, warum man eine Zertifizierung braucht und auch für wen sich eine Zertifizierung lohnt, ist immer so eine Frage. So einfach lässt sich das nicht beantworten, da dort viele Faktoren reinspielen. Es gibt einige (vor allem junge) Leute, die mehrere Zertifizierungen „sammeln“ ohne je praktische Erfahrung gesammelt zu haben. Sieht zwar schön aus, hat nur keinen wirklichen Mehrwert. Die Praxis ist wichtig! Andersrum gilt das gleiche: Wer tagtäglich über mehrere Jahre mit Tools arbeitet, für die es Zertifizierungen gibt, braucht es vermutlich auch eher nicht.

Ich, für meinen Teil, hatte verschiedene Gründe, weshalb ich mich ran gewagt habe:

  • Ich wollte neben meiner praktischen Erfahrung für den Heimgebrauch wissen, was mir grundsätzlich noch fehlt.
  • Ich muss generell für meinen Job wissen, wie Kubernetes grundsätzlich funktioniert und wie DevOps-Teams ihre Anwendungen in den Cluster bekommen.
  • Ich hab nach Absolvierung meines Studiums vor ein paar Jahren Prüfungssituationen vermisst. (Wer hier Ironie findet, darf sie gern behalten.)
  • Es ist generell bei uns auf der Arbeit gewünscht, sich fortzubilden, die Kosten des Kurses wurden auch übernommen.

Prüfungsvorbereitung

Am wenigsten Zeitaufwand für die Vorbereitung auf die Prüfung hat man, wenn man gute Erfahrung in Kubernetes hat. Welch Überraschung. Konkret geht es allerdings in der Prüfung ja darum, vor allem Anwendungen auf ein Kubernetes-Cluster zu deployn und auch Änderungen von deployten Anwendungen durchführen zu können, wo etwa ein fehlerhaftes Deployment schon liegt.

Die CNCF überarbeitet regelmäßig die Curricula für alle Zertifizierungen, und ist somit meist recht aktuell für eine aktuelle Kubernetes Version. Die aktuellen Informationen, inklusive der Gewichtung aller Themenblöcke finden sich in diesem GitHub-Repository.

Meine Prüfung fand im Juni 2021 statt, war also noch ein etwas älterer Stand.

Zur Prüfungsvorbereitung habe ich zwei Dinge genutzt: ein Video-Kurs von Sander van Vugt und das Buch Certified Kubernetes Appliaction Developer Study Guide. Ich habe Zugriff über den Arbeitgeber auf O’Reilly Learning Plattform, wo beides enthalten war. Weiteren Kosten sind daher nicht entstanden.

Ich hab mir zwar beides angeschaut, allerdings vieles nur überflogen, um möglichst herauszufinden, was es bei der Prüfung zu beachten gibt und die Übungen zu machen. Das eigentliche Doing war mir zumindest größtenteils bekannt. Ein paar Tipps meinerseits folgen gleich.

Wenn man die Grundlagen und die Themen aus dem Curriculum so weit beherrscht, empfehle ich strengstens ein paar Übungsaufgaben zu machen und die Zeit dazu auch zu stoppen. In der Prüfung hat man zwei Stunden Zeit, das ist knapp und man hat nur wenig Zeit bei Problemen etwas zu debuggen.

Folgende zwei GitHub-Repositories mit Beispielaufgaben und -lösungen habe ich verwendet, um zu verifizieren, dass ich es so weit kann:

Wer diese Aufgaben ohne Probleme in der Zeit lösen kann, sollte keine Probleme bei der Prüfung haben.

Prüfung

Zur Prüfung gibt es zwei Themen zu bereden:

  • Die „Vorbereitung“ auf die technische Durchführung der Prüfung ist super ätzend
  • Tipps und Hinweise zur Prüfung selbst

Nun, die Prüfung wird komplett Online durchgeführt. Man muss so gut wie alles vom Tisch und den Wänden nehmen, damit man nicht spicken kann. Das wird ausführlich überprüft, in dem man von einer Person im Chat unterhält. Leider ist die Person wenig verständlich gewesen bei mir, sodass sich das ganze etwas gezogen hat und ich ganze 30 Minuten damit beschäftigt war zu „beweisen“, dass ich einen leeren Tisch und leere Wände habe.

Zusätzlich muss man seinen Desktop komplett freigeben über eine Chrome Extension, weil nur ein Tab mit der Kubernetes Dokumentation offen sein darf und die Prüfung selbst. Andere Anwendungen dürfen nicht laufen. Ja, auch das war super nervig, da ich den „Taskmanager“ zeigen sollte, um zu zeigen, dass nichts läuft. Ich sollte dann noch „alle Anwendungen“ beenden, obwohl nur noch KDE/Plasma Desktop-Teile liefen. Die hätte ich gerne beenden sollen. Ach ja und die Lautsprecher, die bei mir quasi fix montiert sind, sollte ich auch runternehmen. Ich durfte dann immerhin über die Webcam zeigen, dass ich es abgestöpselt habe.

Nach diesen 30 Minuten hatte ich schon echt kaum Lust auf die Prüfung, aber da musste ich dann durch. Die Prüfung ist komplett praktisch. Sodass man diverse Umgebungen gestellt bekommt, wo man die Übungen absolvieren muss. Das hat immerhin problemlos funktioniert.

Folgende Tipps allerdings noch meinerseits, damit die Prüfung erfolgreich absolviert werden kann:

  • Versucht so viel YAML-Code durch kubectl generieren zu lassen wie möglich. Das spart sehr viel Zeit, die sonst fehlen würde. Außerdem wollt ihr nicht YAML korrigieren wollen in so einer Situation. (Und auch sonst nicht.)
  • Wenn ihr Probleme mit dem Lösen von Aufgaben habt, überspringt es zunächst und macht alles, was ihr ohne Probleme schafft.
  • Je mehr Übungen man vorher macht, desto einfacher wird es in der Prüfung selbst.
  • Macht euch gewohnt an die Kubernetes Dokumentation und wie man da über die interne Suche was findet. Googeln darf man nicht.

Innerhalb von 24h bekommt man die Resultate. Man braucht 66 von 100 Punkten. Ich habe 87 erreicht. Unabhängig von der eher nervigen Prüfungsorganisation vor dem Ablegen der Prüfung, habe ich gut was gelernt, da ich in meinem Homelab ja auch nicht alles nutze und brauche.

  1. Kommentar: Debian und Firefox – Lieber in Schönheit sterben?
  2. Debian – Die Problem sind größer als Firefox
  3. Debian und Firefox – Nicht Mesa sondern Rust als Problem
  4. Debian – Verzögerung bei Sicherheitsaktualisierungen
  5. Debian und Sicherheit – Risiko Rendering-Engines
  6. Debian und Sicherheit – Die empfohlenen Tools liefern unvollständige Daten

Debian hat einige Probleme und es entsteht der Eindruck, dass das Projekt nicht willens oder nicht fähig ist, auf diese Probleme angemessen zu reagieren. Ein paar Nachträge zum letzten Blogartikel.

Kürzlich hatte ich über Debians Probleme mit Firefox berichtet und das zum Anlass für eine relativ pauschale Kritik genommen. Das war vermutlich ein wenig verkürzt, deshalb möchte ich hier einen zweiten Teil hinterher schieben.

Zustandsbeschreibung

Debian hat ein Problem mit der Sicherheit seiner Distribution. Das ist nicht erst seit den Problemen mit Firefox so. Chromium hat man schon vor Längerem aufgegeben und viele andere Pakete auch – aber ohne sie aus der Distribution zu entfernen. Es ist sowieso schon erstaunlich, wie lange dieser Missstand unkommentiert hingenommen wurde. Wer also darauf vertraut, dass alles, was er über die Paketquellen installiert, sicher ist, der irrt. Meiner Meinung nach kann es nicht der Anspruch an den Anwender sein, dass er bei jedem Programm erst mal eine intensive Zustandsprüfung vornehmen muss.

Vermutlich sind die bekannten Probleme rund um die Browser nur die Spitze des Eisbergs. Die Debian-Paketquellen sind, was ihren Umfang betrifft, unerreicht im Linux-Universum. Bereits seit Längerem mutmaßen viele, dass es durch Debians Updatepolitik Probleme z. B. im Qt-Stack geben könnte, weil man hier bewusst nicht auf LTS-Varianten gesetzt hat und Updates nicht einfach weiterreicht. Die Probleme betreffen aber nicht nur den Desktop. Debian liefert auch viele Serveranwendungen aus. Enthalten z. B. die Versionen von WordPress in Stable (5.7.1) oder Oldstable (5.0.14) wirklich alle danach erfolgten Sicherheitspatches? Zweifel sind wohl erlaubt.

Auf Veränderungen nicht reagiert

Debians Richtlinien zur Softwarepaketierung haben sich seit vermutlich 20 Jahren kaum grundsätzlich verändert. Im Laufe einer Testingphase werden Pakete in die Quellen aufgenommen und während des Freeze stabilisiert. Danach gilt das Primat der Versionsstabilität und es sind lediglich Patches erlaubt, die einzelne Probleme adressieren. Meist sind diese sicherheitsrelevant, es können aber auch ordinäre Bugs auf diese Weise behoben werden, wenn sie gravierend genug sind.

Die Softwareentwicklung hat sich in den letzten 20 Jahren aber verändert. Es gibt nicht mehr alle paar Jahre eine neue Programmversion, sondern die Zyklen umfassen meist nur wenige Monate oder gar Wochen. Manche Software gibt es gar nur noch als sogenannten Entwicklungsschnappschuss. Die Upstream-Entwicklung ist durch das Tempo der Entwicklung nicht unbedingt besser dokumentiert. Welche Änderungen genau vorgenommen wurden, was welche Probleme behebt und was sicherheitsrelevant ist, bleibt oft intransparent. Selbst KDE ist mit wirklicher LTS-Pflege überfordert, wie Nate Graham kürzlich schrieb. Ich bin sicherlich der Letzte, der das gut findet, mein Faible für LTS-Versionen habe ich schon oft erklärt, aber es ist die Realität, mit der alle im Linux-Umfeld arbeiten müssen.

Um hier wenigstens die sicherheitsrelevanten Probleme zu adressieren und in die Debian-Versionsstände zurück zu portieren, braucht es viel Zeit und die notwendigen Fähigkeiten. Hier kann man die Debian-Paketquellen sicher nicht über einen Kamm scheren. Manche Maintainer haben mehr Zeit oder werden sogar dafür bezahlt, andere machen es nur in ihrer Freizeit. Manche Upstream-Projekte lassen sich auch leichter pflegen als andere. In der Summe hat Debian aber Probleme genug aktive Paketbetreuer mit den notwendigen Fähigkeiten zu gewinnen. Das ist eine alles andere als geheime oder neue Erkenntnis.

Debian ist nicht alleine

Das Problem betrifft nicht nur Debian, sondern alle stabilen Distributionen, denn im Gegensatz zu Rolling Release-Distributionen, können sie nicht einfach die Upstream-Versionen durchreichen. Besonders betroffen sind jene Distributionen mit besonders langen Supportversprechen, was gemeinhin mit LTS oder Enterprise umschrieben wird und bei Debian einfach Stable heißt.

Ubuntu hat deshalb schon immer sein Supportversprechen auf den Teil der Pakete in main beschränkt. Inzwischen arbeitet man an einer Kooperation mit Mozilla, um die aufwendige Firefox-Pflege an die eigentlichen Entwickler auszulagern. Das hat sicher andere Probleme zur Folge, aber es ist der Versuch ein Problem zu lösen, vor dem die Distrubution steht. Möglicherweise steuert man hier auch noch mal nach, Irrtümer und Lernprozesse sind schließlich erlaubt.

Jenseits der Debian-Abkömmlinge ist man im LTS-Segment andere Wege gegangen. Das finanzstarke Red Hat unterstützt für sein RHEL nur einen einzigen Desktop und einen kleinen Paketpool für den Desktop. Das openSUSE-Projekt hat für seine stabile Variante die Kooperation mit SUSE gesucht und pflegt nur noch die Differenz zwischen SUSE Linux Enterprise und openSUSE Leap, also jene Pakete, die nur in openSUSE und nicht in SLE enthalten sind.

Alle hier genannten Distributionen sind dabei weniger dogmatisch. Vielen Debian-Nutzern ist das nicht bewusst, weil sie selten über den Tellerrand schauen, aber Paketupdates bedeuten nicht gleich den Zusammenbruch des Systems.

Bei SLE/openSUSE Leap werden durchaus in einem gewissen Rahmen Updates vorgenommen, wenn der Nutzen das Risiko übersteigt. So hat man z. B. Samba von 4.13.4 auf 4.13.13 angehoben oder systemd von 246.13 auf 246.16. Nur um ein paar Kernbeispiele zu zeigen. Ein mal pro Jahr macht man mit den Servicepacks (SLE) bzw. Minorversinen (RHEL, openSUSE Leap) sogar noch größere Sprünge, um das Qualitätsversprechen zu erfüllen.

RHEL und SLE sind und bleiben trotzdem Enterprise-Distributionen, für die viele Unternehmen erhebliche Beträge bezahlen. Warum klappt dort, was Debian partout nicht machen möchte?

Nichts tun ist keine Lösung

Es gibt kein Patentrezept, aber nichts tun ist keine Lösung für eine renommierte Distribution mit dem Selbstanspruch, eine sichere und stabile Basis für die Anwender bereitzustellen.

Für Außenstehende entsteht manchmal der Eindruck, dass bei Debian mehr um ideologische Fragen wie systemd gestritten wird als um wirklich kritische Sachverhalte.

Das Problem in den Release Notes zu verstecken, wie man es jahrelang mit den Browsern machte, keine Kommunikation wie bei Firefox aufzunehmen und einfach weiter zu machen – das kann aber nicht die Lösung sein. Vermutlich wird aber exakt das passieren.

Der Artikel Debian – Die Problem sind größer als Firefox erschien zuerst auf [Mer]Curius

11. Dezember 2021

Tor ist immer wieder das Ziel dunkler Verschwörungserzählungen. Die einen sehen im Darknet nur Terrorismus, die anderen argwöhnen dunkle Machenschaften, weil das Tor Projekt substanziell durch die USA finanziert wird. Letztlich ist Tor aber das einzige wirklich probate Mittel zur Anonymisierung im Internet.

Dass dem so ist, sieht man an den Meldungen, die jüngst aus Russland kamen. Der Kreml versucht seit Längerem, das russische Internet nach außen abzuschirmen. Die russische Zivilgesellschaft und ihre intellektuelle und technische Fähigkeit, die staatliche Propagandamaschinerie zu umgehen und sich mit unabhängigen und seriösen Informationen zu versorgen, sind für den Kreml ein stetes Ärgernis. Als Vorbild hat man sicherlich das vollkommen regulierte chinesische Intranet. Momentan versucht Russland massiv das Tor-Netzwerk zu stören. Das ist kein Problem für Tor direkt, wohl aber für die circa 300.000 russischen Tor-Nutzer.

Gleichzeitig hat Tor momentan noch ein weiteres viel gravierenderes Problem. Die Tor-Knoten waren schon immer die bekannte Schwachstelle im Netz. Kontrolliert ein Akteur genug Knoten, kann theoretisch eine Deanonymisierung der Nutzer erfolgen. Die Anfälligkeit des Netzes für eine Massenüberwachung ist seit vielen Jahren bekannt.

Ein Problem dabei ist die relativ geringe Anzahl an Tor-Knoten, wodurch der Aufwand, großflächig ins Tor-Netzwerk einzusteigen für z. B. staatliche Akteure durchaus möglich ist. Momentan sollen es nur knapp 7000 Tor-Knoten geben. Wie in den letzten Tagen gemeldet wurde, läuft möglicherweise schon seit 2017 der Versuch, das Tor-Netzwerk über manipulierte Knoten zu kompromittieren.

Eine Gruppe, KAX17 genannt, betreibt momentan vermutlich bis zu 900 solcher Knoten. Das ist grundsätzlich nicht verboten, aber gemessen an anderen Betreibern sind das exorbitant viele. Diese besitzen zudem nicht näher beschriebene Sonderfähigkeiten. Herausgefunden hat das ein Tor-Community Mitglied mit dem Pseudonym „nusenu“. Das ist kein abstraktes Risiko, denn die Wahrscheinlichkeit, beim Surfen via Tor über einen dieser potenziell kompromittierenden Tor-Knoten geleitet zu werden, unterscheidet sich je nach Eintritts-, Weiterleitungs oder Exit-Node aber liegt bei einem Weiterleitungsknoten in der Mitte der Kette bei bis zu 32 %. Das Tor-Projekt hat versucht die verdächtigen Knoten zu blockieren, aber der Akteur kam schnell mit neuen Knoten zurück.

Ob KAX17 wirklich beabsichtigt, das Tor-Netzwerk zu deanonymisieren ist natürlich nicht klar – wohl wären sie aber dazu in der Lage. Aufgrund des hohen Aufwands und der unklaren Stoßrichtung der Maßnahme gehen Projektbeteiligte von einem staatlichen Akteur hinter KAX17 aus.

Sollte das Tor-Netzwerk nachhaltig kompromittiert werden, wäre das ein gravierender Verlust. Nicht nur aber insbesondere für Untertanen verbrecherischer Autokratien/Diktaturen, wie das Beispiel Russland zeigt. Es gibt aber auch für Bürger rechtsstaatlicher Demokratien keine andere Möglichkeit außer Tor, um wirklich anonym im Internet unterwegs zu sein.

Der Artikel Tor im Fokus – KAX17 und Sperre in Russland erschien zuerst auf [Mer]Curius

10. Dezember 2021

LineageOS ist oftmals die einzige Möglichkeit, ein alternatives Betriebssystem auf Android-Hardware aufzuspielen. LineageOS hat viele Probleme und auf manches wurde hier im Blog bereits eingegangen. Wichtig ist ein Verständnis für den Unterschied von Sicherheit und Datenschutz.

In der neuen Serie zu GrapheneOS und vor allem im ersten Teil hatte ich einen extrem kritischen Blick auf LineageOS und vergleichbare Systeme wie Murena bzw. /e/ geworfen. Der Grund dafür ist schlicht und ergreifend: Sie sind nicht sicher. Sie sind sogar unsicherer als die meisten Stock Android-Systeme. Mit diesen Aussagen hatte ich für Verunsicherung gesorgt und möchte das deshalb noch ein wenig präzisieren.

Die an LineageOS beteiligten Entwickler leisten tolle Arbeit und viele der Geräte-Maintainer bemühen sich sehr die Geräte bestmöglich zu unterstützen und mehr als nur die AOSP-Updates weiterzureichen. Von dieser tollen Arbeit habe ich z. B. bei meinem Samsung Galaxy S10 das ganze Jahr profitiert. Diese Entwickler können aber nur mit den Möglichkeiten arbeiten, die ihnen die Hardware bietet. Vor allem im Bereich der Sicherheit führt das nicht weit.

Grundsätzlich ist hier der Unterschied von Datenschutz und Sicherheit zu beachten, der durch eine pauschale Verwendung beider Begriffe und ihrer permanenten Vermengungen vielen nicht ganz klar ist.

Beim Datenschutz geht es schlicht darum, dass mit meinen Daten kein Schindluder getrieben wird. Das Versprechen natürlich alle Unternehmen, aber weil es nicht überprüfbar ist, gibt es das Prinzip der Datensparsamkeit. Das bedeutet, Daten, die nicht erhoben werden, können auch nicht missbräuchlich verwendet oder entwendet werden. Datensparsamkeit als Prinzip gerät immer stärker aus dem Blickfeld, vor allem wenn digitale Werbung ins Spiel kommt. Android ist in seiner normalen Variante so ziemlich das exakte Gegenteil von Datensparsamkeit.

Nutzt man also ein LineageOS ohne Play Services und Play Store und überwiegend oder gar ausschließlich mit freien Apps von F-Droid, dann minimiert man die Datenabflüsse vor allem zu Google immens. Das gilt aber wirklich nur dann. Sobald man den Play Store nutzt oder massiv proprietäre Apps mit den obligatorischen Bibliotheken von Google, Facebook & Co, sind die Datenschutzgewinne schnell dahin. LineageOS ist in seiner Basisvariante ohne Play-Dienste für den Datenschutz ziemlich gut geeignet. Ein paar kleinere Handgriffe, um die letzten Datenabflüsse an Google zu unterbinden, kann man als Anwender selbst noch erledigen, aber die Standardkonfiguration ist ziemlich gut.

Bei der Sicherheit geht es weniger um Telemetriedaten oder Tracking im Internet, sondern um wirklichen Abfluss von gespeicherten Daten, möglicherweise gar die Kompromittierung des Geräts mit dem Ziel, den Besitzer zu überwachen. Die Liste der Opfer in der Pegasus-Affäre sollte einem vor Augen führen, dass der potenziell betroffene Personenkreis größer ist, als man so denkt. Diese Form der Überwachung wird vermutlich eher zu- denn abnehmen. Der auch in Europa zu beobachtende Aufstieg der Autokratien mit ihren vielen imaginierten internen und externen Feinden dürfte seinen Teil dazu beitragen. Viele der NSO-Opfer hätten nicht gedacht, dass sie gezielt überwacht werden. Und hier kommen die Nachteile von LineageOS zum Tragen.

Der Übersichtlichkeit fasse ich die wichtigsten Probleme in einer Liste zusammen:

  • Bestenfalls besitzt man ein offiziell unterstütztes Gerät, ansonsten bezieht man bereits das Betriebssystem über Foren wie XDA Developers und damit über eine definitiv nicht vertrauenswürdige Quelle.
  • LineageOS garantiert keine Updatezeiträume. Geräte können jederzeit ohne Angabe von Gründen aus dem Support fallen und erhalten dann keine Sicherheitsupdates mehr. Wenn der Maintainer nur zeitweilig das Interesse verliert, fällt das dem Anwender vermutlich nicht mal auf, weil die wöchentlichen LinageOS-Updates trotzdem kommen – halt nur ohne die monatlichen Herstellerupdates.
  • Fehlende Updates von Firmware und schlimmstenfalls sogar Kernel machen das Smartphone, abhängig vom Modell, Monat für Monat angreifbarer.
  • Für die Installation muss man den Bootloader öffnen, der danach auch nicht mehr geschlossen werden kann. Der verifizierte Start ist damit unmöglich und es ist für Angreifer mit physischem Zugriff auf das Gerät relativ leicht das System zu manipulieren.
  • Viele auf XDA Developers verbreiteten Betriebssysteme deaktivieren gar die dateibasierte Verschlüsselung von Android, um über ein Recovery wie TWRP jederzeit auf die Daten zugreifen zu können. Wodurch aber eben selbst blutige Anfänger problemlos per Anleitung aus dem Netz Daten vom Gerät auslesen könnten.
  • Die nicht zu erklärende Beliebtheit des „Rootens“ führt zu noch mehr Problemen. Der Anwender hat nun Rootrechte auf seinem System, die er mit dubiosen Tools wie Magisk eingezogen hat. Damit kann der Anwender per Definition einfach alles mit dem Gerät anstellen. Das gilt natürlich auch für Schadsoftware, die man sich irgendwie einfängt.

Aus diesen Gründen ist LineageOS unter den richtigen Voraussetzungen zwar gut für den Datenschutz, aber schlecht bis katastrophal für die Sicherheit. Das ist ein nicht aufzulösender Widerspruch mit dem Anwender leben müssen, so sie nicht Hardware oder Betriebssystem wechseln möchten. Ob das jetzt ein Problem darstellt, hängt von den Einsatzszenarien und der individuellen Risikoanalyse ab.

Der Artikel LineageOS – Datenschutz ungleich Sicherheit erschien zuerst auf [Mer]Curius

Es war nur eine Frage der Zeit: Malware, versteckt in einem vermeintlich interessanten Download, machte das Modem des PinePhone unbrauchbar. Es zeigt sich leider: Linux ist im mobilen Bereich nett zum basteln, aber meilenweit von den Standards entfernt, die Android oder iOS heute setzen.

Über den Fall berichtete GNU/Linux.ch und der Vorfall ist schnell beschrieben: Ein bösartiger Entwickler versteckte die Malware in einem vermeintlich interessanten Download. Die Malware nutzte eine länger bekannte Sicherheitslücke aus und führte mit Root-Rechten Code auf dem Modem des Gerätes aus.

Bösartige Entwickler und Malware sind natürlich kein exklusives Problem für Linux im Smartphone-Bereich. Insbesondere Android ist davon auch in schöner Regelmäßigkeit betroffen. Der Fall zeigt sehr schön, warum die Linux-Systeme im mobilen Bereich zwar eine nette Bastelei, aber meilenweit von Produktivität oder nur minimalen Sicherheitsstandards entfernt sind.

Vier Stichpunkte dazu:

  • Software aus Downloads „im Internet“
  • Rootrechte auf dem Gerät
  • Keine Sandboxes oder irgendwelche Rechtebeschränkungen für Apps
  • Offene Sicherheitslücken

Im mobilen Bereich hat sich bei der Sicherheit einfach in den letzten Jahren wahnsinnig viel getan – sowohl bei Android als auch bei iOS. Beide Systeme haben sich da ein durchaus produktives Wettrennen geliefert, angeheizt von einer sensiblen Öffentlichkeit, die entsprechende Verbesserungen honoriert hat.

Linux auf dem Smartphone kommt hingegen mit ähnlichen Prinzipien wie Linux auf dem Desktop. Das dürfte schon am Desktop nur deshalb ausreichen, weil die geringe Verbreitung Linux zu keinem attraktiven Ziel macht. Für Smartphones mit ihren vielen Sensoren und zusätzlichen Angriffsvektoren reicht es sicher nicht.

Deshalb sollte man tunlichst nicht auf irgendwelche Privacy-Versprechen hereinfallen, die durch „Kill-switches“ für WLAN, Bluetooth etc. suggeriert werden. Linux ist am Smartphone nett, wenn man Spaß hat an solchen Sachen herumzuspielen, aber mehr wirklich nicht.

Der Artikel Malware machte Modem des PinePhone unbrauchbar erschien zuerst auf [Mer]Curius

Fr, 10. Dezember 2021, Marco

Das Team hinter Kali Linux hat gestern die Version 2021.4 veröffentlicht. Die aktuelle Version bringt eine bessere Unterstützung für Apples M1-Chip, Aktualisierungen bei den Desktopumgebungen sowie neue zusätzliche Tools mit. Kali Linux basiert auf der Linuxdistribution Debian und richtet sich primär an Personen, welche Sicherheitstests von Anwendungen durchführen.

Wie bereits erwähnt, wurde die Unterstützung für die neuen M1-Prozessoren von Apple verbessert. Ausserdem wurde die Unterstützung für VMware erweitert, sodass der Installer die Installation mit VMware automatisch erkennt und installiert dann zusätzlich das Paket open-vm-tools-desktop, welches dafür sorgt, dass die Grösse des Fensters angepasst werden kann. Im Blogbeitrag wird beschrieben, dass dies aktuell noch eine Vorschau von VMware sei und daher noch Fehler zu erwarten sind. Die Konfiguration des Samba-Clients ist jetzt auf mehr Kompatibilität ausgelegt, wodurch das Aufspüren von alten Samba-Servern einfacher geschehen kann.

Durch die Aktualisierung von Kaboxer – einem Tool zur Verwaltung von Anwendungen innerhalb von Containern – ist es möglich, dass sich diese Anwendungen besser in das Systemtheme integrieren. Bisher waren die Fensterbuttons hauptsächlich an die Desktopumgebung Xfce angepasst. Neu wurden diese Buttons für die unterstützten Desktopumgebungen angepasst, sodass unter anderem einfach ersichtlich ist, welches Fenster gerade fokussiert wird.

Neben den vereinheitlichten Buttons wurden auch die Desktopumgebungen aktualisiert und weiter angepasst. In der Xfce-Variante wurden beispielsweise zwei neue Widgets und ein Shortcut für die PowerShell hinzugefügt. Die GNOME-Variante kommt mit GNOME 41 und bietet für die Anwender einige Neuigkeiten, da zuvor die Version 3.38 eingesetzt wurde. Die Desktopumgebung KDE wurde auf die Version 5.23 aktualisiert und standardmässig wird neu das Theme Breeze verwendet.

Zusätzlich zu den unzähligen Aktualisierungen wurden auch einige Tools neu hinzugefügt. Darunter gehören auszugsweise Maryam (ein Open-Source Intelligence Framework), S3Scanner (dient zum Auffinden von öffentlichen S3-Buckets und dem Auslesen des Inhalts) sowie truffleHog (sucht in Git-Repositories nach Strings, welche sensible Daten beinhalten). In der Quelle sind sämtliche Änderungen sowie Links für den Download der neusten ISO-Dateien ersichtlich.

Quelle: https://www.kali.org/blog/kali-linux-2021-4-release/

  1. Kommentar: Debian und Firefox – Lieber in Schönheit sterben?
  2. Debian – Die Problem sind größer als Firefox
  3. Debian und Firefox – Nicht Mesa sondern Rust als Problem
  4. Debian – Verzögerung bei Sicherheitsaktualisierungen
  5. Debian und Sicherheit – Risiko Rendering-Engines

Debian scheitert daran, für seine stabilen Versionen sicheren Browser auszuliefern. Damit ist es als Desktop-Betriebssystem ungeeignet. Die Entwickler scheinen sich entschieden zu haben, lieber in Schönheit zu sterben als notwendige Änderungen vorzunehmen.

Per E-Mail wurde ich auf folgenden Artikel auf Phoronix aufmerksam gemacht. Nun ist meine kritische Sicht auf Debian nicht neu, aber nun scheinen die Entwickler endgültig beschlossen zu haben, ihren Dogmatismus höher zu gewichten als den praktischen Nutzen der Distribution. Jedenfalls sofern sich die beim Debian-Release bereits deutlich veraltete Mesa-Version als Knackpunkt herausstellen sollte.

Bereits seit Längerem kann Debian nahezu alle Browser nicht mehr zeitnah oder gar nicht mit Sicherheitsupdates versorgen. Es ist schon blamabel genug diese toxischen Pakete überhaupt noch auszuliefern, anstelle sie einfach aus der Distribution zu entfernen. Bereits hier gewichtet Debian den Paketierungsprozess höher als den Nutzen und behält lieber gefährliche Pakete im System als diese im Freeze zu entfernen.

Die einzige rühmliche Ausnahme war bisher Firefox, den man in der ESR-Version ausrollt. Hier wurde vor Kurzem die ESR-Version aktualisiert. Anstelle der Version 78.x ist nun die 91.x die gültige ESR-Version. Die letzte Aktualisierung von Firefox 78 gab es am 5. Oktober 2021. Die Zahl der bekannten Sicherheitslücken geht damit natürlich quasi jeden Tag weiter in die Höhe. Das ist bei Browsern leider fast schon ein Naturgesetz.

Ein sicherer Browser ist das Herzstück eines sicheren Desktopbetriebssystems, das muss hier sicher nicht verdeutlicht werden. Mit einem aktuellen Browser kann man viel kompensieren und umgekehrt nützen einem viele Sicherheitsupdates wenig, wenn der Browser gleichzeitig einem Scheunentor gleich offen steht.

Laut Phoronix ist dieser Fehler die Ursache für das fehlende Update bei Debian. Firefox ist mit der neuen Version von OpenGL GLX auf EGL umgestiegen. Dafür benötigt man angeblich ein aktuelleres Mesa als Debian ausliefert. Debian liefert in Stable Mesa 20.3.5 aus. Den Wechsel auf Mesa 21 kam für Debian zu spät. Die Veröffentlichung im April 2021 lag zwar noch vor dem Release von Debian im Sommer aber der Debian-Freeze verhinderte eine Aufnahme.

Nun ist Debian nicht die einzige LTS-Distribution. Andere Distributionen wie z. B. Ubuntu sind nur weniger dogmatisch und aktualisieren Mesa oder scheinen wie SUSE die notwendige Expertise zu haben, das Problem zu umgehen. In SUSE Linux und openSUSE Leap ist die neue ESR-Version trotz alter Mesa-Version nämlich bereits enthalten. Und das nicht erst 2 Monate nach dem letzten Update von Firefox.

Debian scheint aktuell immer größere Schwierigkeiten zu haben, den Spagat zwischen den Kapazitäten oder Fähigkeiten seiner Entwickler und den dogmatischen Paketierungsrichtlinien zu bewältigen. Versionen stabil halten und massiv Patches zurückportieren, muss man halt auch können und nicht nur im Anspruch formulieren.

Auf den Vorgang haben sicher noch mehr ein Auge, denn wenn Debian es nicht mehr hinbekommt wenigstens einen einzigen aktuellen Browser ohne Sicherheitslücken auszuliefern, ist die Distribution für den Desktopeinsatz nicht mehr geeignet.

Der Artikel Kommentar: Debian und Firefox – Lieber in Schönheit sterben? erschien zuerst auf [Mer]Curius

9. Dezember 2021

Vor einigen Tagen machte eine Meldung die Runde, dass Anwendungen, welche Mozillas NSS-Bibliothek nutzen, von einer „BigSig“ getauften Sicherheitslücke betroffen waren. Nachdem Unklarheit herrschte, ob Thunderbird 91.4 die Sicherheitslücke geschlossen hat, soll dieser Artikel für Aufklärung sorgen.

Was ist „BigSig“?

BigSig ist der inoffizielle Name einer bereits seit Jahren existierenden, aber jetzt erst bekannt gewordenen Sicherheitslücke in den Network Security Services, kurz: NSS. Dabei handelt es sich um eine von Mozilla entwickelte Bibliothek, welche nicht nur in Firefox, sondern auch in anderen Anwendungen wie Thunderbird, LibreOffice, Evolution und Evince verwendet wird – und noch weiteren hier nicht genannten Anwendungen. Firefox selbst war von der Sicherheitslücke nicht betroffen.

An dieser Stelle möchte ich gar nicht auf die technischen Details von „BigSig“ eingehen. An dieser Stelle nur so viel: Bereits der Empfang einer S/MIME signierten E-Mail hätte eine Attacke einleiten können.

Mozilla behebt „BigSig“-Sicherheitslücke

Mozilla hat die Sicherheitslücke in NSS 3.68.1 respektive NSS 3.73 behoben. Anwendungen, welche NSS verwenden, müssen ihrerseits ein Update mit der aktualisierten NSS-Bibliothek ausliefern.

Thunderbird 91.4 liefert Sicherheits-Fix für „BigSig“ aus

Verwirrung herrschte nun teilweise darüber, ob das neuste Thunderbird-Update auf Version 91.4 die Sicherheitslücke geschlossen hat oder nicht. Teilweise wurde sogar auf Websites geschrieben, dass Thunderbird 91.4 die Sicherheitslücke nicht geschlossen hätte.

Tatsache ist jedoch, dass die „BigSig“-Sicherheitslücke in Thunderbird 91.4 geschlossen worden ist.

Grund für die Verwirrung ist vermutlich, dass die Liste geschlossener Sicherheitslücken in Thunderbird 91.4 nichts in dieser Art erwähnt. Das liegt aber daran, dass es sich dabei um keine Sicherheitslücke in Thunderbird selbst, sondern in NSS handelte, und Mozilla für NSS einen eigenen Sicherheits-Hinweis veröffentlicht hat.

Mozilla hat NSS im ESR-91-Zweig am 1. Dezember auf Version 3.68.1 aktualisiert. Thunderbird 91.4, der auf Mozillas ESR 91-Zweig basiert, nutzt den Code mit dem Stand vom 3. Dezember und damit bereits die gepatchte Version NSS 3.68.1.

Der Beitrag Thunderbird 91.4 behebt BigSig-Sicherheitslücke erschien zuerst auf soeren-hentzschel.at.

8. Dezember 2021

Mozilla hat seinen Finanzbericht für das Jahr 2020 veröffentlicht. Dieser zeigt einen gesteigerten Umsatz, der bei knapp einer halben Milliarde USD liegt, bei gleichzeitig reduzierten Ausgaben.

Wie jedes Jahr am Jahresende hat Mozilla auch in diesem Jahr seinen Finanzbericht für das Vorjahr veröffentlicht, welcher offenlegt, in welcher Höhe Mozilla Einnahmen und Ausgaben hatte.

Mozilla steigert seinen Umsatz

Normalerweise würde man den Umsatz mit dem des Vorjahres vergleichen. Dies gestaltet sich dieses Mal etwas schwieriger. Zwar hatte Mozilla im Jahr 2019 einen Rekordumsatz in Höhe von 828 Millionen Dollar erzielt, dieser beinhaltete jedoch eine Vergleichszahlung aus einem Rechtsstreit mit Yahoo!, deren Höhe schätzungsweise im Bereich von 338 Millionen Dollar lag. Ausgehend von dieser Zahl hätte der Jahresumsatz in 2019 ohne diese Zahlung bei 490 Millionen Dollar gelegen.

Da es sich bei der Vergleichszahlung um eine einmalige Zahlung handelte, soll an dieser Stelle für den Umsatz ausnahmsweise die Zahl aus dem vorletzten Jahr als Vergleichsbasis dienen.

2018 hatte Mozilla einen Umsatz 450 Millionen erzielt. Im Jahr 2020 lag Mozillas Umsatz bei 497 Millionen Dollar, was gegenüber 2018 einem etwas größeren Plus und gegenüber der geschätzten Zahl aus 2019 immerhin noch einem kleinen Plus entspricht.

Weniger Abhängigkeit von Suchmaschinen, mehr Einnahmen durch Abo-Dienste und Werbung

Seine finanzielle Abhängigkeit von Suchmaschinen hat Mozilla dabei weiter reduziert. Bestand 2017 noch eine 93 prozentige Abhängigkeit von der primären Standard-Suchmaschine, aktuell Google, waren es 2018 noch 91 Prozent, 2019 noch 88 Prozent und im Jahr 2020 nur noch 86 Prozent.

Das im Vorjahr bereits von 5,3 Millionen auf 14 Millionen Dollar Umsatz gesteigerte Geschäft mit Abonnement- und Werbeeinnahmen konnte Mozilla auf einen Umsatz von knapp 25 Millionen Dollar steigern. Dafür verantwortlich ist in erster Linie das Premium-Angebot von Mozillas Read it Later-Dienst Pocket, außerdem das im letzten Jahr in ersten Ländern gestartete Mozilla VPN sowie bezahlte Platzierungen auf der Standard-Startseite von Firefox.

Verringerung der Ausgaben

Gleichzeitig hat Mozilla seine Ausgaben gesenkt. Hatte Mozilla im Jahr 2018 noch Ausgaben in Höhe von 451 Millionen Dollar und im Jahr 2019 sogar in Höhe von 495 Millionen Dollar, lagen die Ausgaben im Jahr 2020 nur noch bei 439 Millionen Dollar. Dabei wurden insbesondere die Ausgaben für Software-Entwicklung von 304 Millionen auf 243 Millionen Dollar gesenkt, aber auch die Marketing-Kosten wurden um fünf Millionen auf 37 Millionen Dollar reduziert.

Mozilla steigert sein Vermögen

Als Ergebnis aus gesteigertem Umsatz und verringerten Ausgaben folgt auch eine Steigerung von Mozillas Netto-Vermögens von 787 Millionen auf 843 Millionen Dollar.

Entwicklung von 2005 bis heute

Wie gehabt gibt es auf soeren-hentzschel.at eine Sonder-Seite, welche die Einnahmen, die Ausgaben sowie das Vermögen von Mozilla seit dem Jahr 2005 bis heute visualisiert und die Entwicklung anschaulich gestaltet. Seit diesem Jahr steht diese auch in englischer Sprache zur Verfügung.

Mozilla-Umsatz 2020
Bildquelle: soeren-hentzschel.at/mozilla-umsatz

Ausblick auf das Jahr 2021

Der Finanzbericht für das Jahr 2021 wird voraussichtlich Ende November bis Mitte Dezember 2022 veröffentlicht werden. Spannend ist dieser insbesondere deswegen, weil Mozilla Ende 2020 seinen auslaufenden Suchmaschinen-Vertrag mit Google um weitere drei Jahre verlängert hat und im Finanzbericht für 2021 zum ersten Mal zu sehen sein wird, wie sich der neue Vertrag finanziell auswirkt.

Auch Mozilla spürt die Folgen der weltweiten Pandemie, was im August 2020 zu einer Kündigung von ungefähr 250 Mitarbeitern sowie zur Schließung seines Standorts in Taiwan führte, nachdem bereits im Januar 2020 die Kündigung von mindestens 70 Mitarbeitern erfolgte, weil Mozilla mit den Gewinnerwartungen für neue Produkte hinter den eigenen Planungen zurückgeblieben war. Nachdem in 2020 noch Abfindungen, bezahlte Sozialleistungen und Prämien in Höhe von über 36 Millionen Dollar für die gekündigten Mitarbeiter zu zahlen waren, dürften sich die eingesparten Gehälter spätestens im Finanzbericht für 2021 durch erneut geringere Ausgaben bemerkbar machen. Aktuell beschäftigt Mozilla in etwa 775 Mitarbeiter weltweit.

Mit zusätzlichen Einnahmen wird durch das Mozilla VPN zu rechnen sein, welches 2020 in ersten Ländern gestartet war, aber erst seit diesem Jahr in neun weiteren Ländern verfügbar ist und um zahlreiche Features und Unterstützung für weitere Plattformen erweitert wurde. Mozilla hat bereits kommuniziert, dass der Umsatz durch das Mozilla VPN im Jahr 2021 um 450 Prozent gegenüber 2020 steigen wird. Außerdem hat Mozilla im November 2021 das Premium-Angebot von Firefox Relay gestartet. Auch die Hubs Cloud ist weiterhin am Start. Insgesamt erwartet Mozilla für das Jahr 2021 eine weitere Umsatzsteigerung sowie einen Umsatz von mehr als 500 Millionen Dollar. Andere Produktangebote als Firefox sollen in diesem Jahr bereits für 14 Prozent von Mozillas Gesamt-Umsatz verantwortlich sein.

Das im letztjährigen Artikel erwähnte Firefox Better Web wird jedoch für keine weiteren Einnahmen sorgen, da dieses Produkt den in den USA durchgeführten Beta-Test nie verlassen hat und eingestellt wurde.

Der Beitrag Mozilla erneut mit Gewinn im Jahr 2020 erschien zuerst auf soeren-hentzschel.at.

Mi, 8. Dezember 2021, Lioh Möller

Die Distribution ZorinOS richtet sich insbesondere an Einsteiger, die sich einen gut vorkonfigurierten Desktop wünschen. Neben der Hauptversion wird üblicherweise mit einiger Verzögerung eine sogenannte Light Variante veröffentlicht, bei der Xfce zum Einsatz kommt.

ZorinOS steht wahlweise kostenfrei (Core) oder mit Erweiterungen (Pro) zum Kauf zur Verfügung. So ist beispielsweise die Möglichkeit, zwischen verschiedenen vorgefertigten Desktop-Layouts zu wechseln, nur in der Pro-Variante enthalten.

Laut Hersteller eignet sich die Light Variante insbesondere für den Betrieb auf älteren Computern. Dabei bringt sie das von ZorinOS bekannte Erscheinungsbild mit, welches auch einen Dark-Mode bietet.

Über den integrierten Software-Center lässt sich das System bei Bedarf erweitern. Flatpak Applikationen werden darüber ebenfalls angeboten.

Die neue Version von ZorinOS Light enthält einen Welcome-Screen, der die wichtigsten Funktionen der Distribution vorstellt. Eine Vielzahl von Windows Applikationen lassen sich auf einfache Weise installieren. Die neu hinzugekommene Sound Recorder Applikation ermöglicht es Audioaufnahmen wie Sprachnotizen in wenigen Schritten zu erstellen.

Als Basis für die aktuelle Version dient Ubuntu 20.04.3 LTS mit XFCE 4.16.

Quelle: https://blog.zorin.com/2021/12/08/zorin-os-16-lite-is-here/
Download: https://zorin.com/os/download/16/lite/

Mi, 8. Dezember 2021, Marco

Die auf Debian basierende Linux-Distribution Tails wurde in der Version 4.25 veröffentlicht. Diese Version bringt ein neues Backuptool sowie weitere Neuigkeiten und Aktualisierungen mit sich. Die Distro setzt es sich zum Ziel, ein möglichst sicheres und anonymes Betriebssystem bereitzustellen.

Die neueste Version von Tails bringt ein neues Werkzeug, mit welchem Backups erstellt werden können. Bis anhin konnten Backups des persistenten Speichers lediglich über die Kommandozeile durchgeführt werden. Dank dem initialen Code von David A. Wheeler gibt es nun die Möglichkeit, über die grafische Oberfläche ein Backup zu erstellen. In den Einträgen des Bootloaders GRUB erscheint neu ein weiterer Eintrag, womit Tails von einem externen USB-Stick resp. einer Festplatte gestartet werden kann, wenn zuvor eine Fehlermeldung erschienen ist, welche besagt, dass kein Live-Dateisystem gefunden werden konnte.

Neben den Neuigkeiten wurde der Tor Browser auf die Version 11.0.2 und diejenige von Tor auf 0.4.6.8 angehoben. Wer die neuste Version von Tails ausprobieren möchte, kann diese auf der Webseite des Projekts herunterladen. Sämtliche Änderungen, welche in der neuen Version durchgeführt wurden, können im Changelog nachgelesen werden.

Quelle: https://tails.boum.org/news/version_4.25/index.en.html

Die MZLA Technologies Corporation hat mit Thunderbird 91.4 ein planmäßige Update für seinen Open Source E-Mail-Client veröffentlicht.

Neuerungen von Thunderbird 91.4

Mit dem Update auf Thunderbird 91.4 hat die MZLA Technologies Corporation ein planmäßiges Update für seinen Open Source E-Mail-Client veröffentlicht und behebt damit aktuelle Sicherheitslücken. Darüber hinaus bringt das Update diverse Fehlerbehebungen der Versionsreihe 91, welche sich in den Release Notes (engl.) nachlesen lassen.

Der Beitrag Thunderbird 91.4 veröffentlicht erschien zuerst auf soeren-hentzschel.at.

Mi, 8. Dezember 2021, Lioh Möller

Mit der Ankündigung in Zukunft keine Point-Releases analog zum Red Hat Enterprise Linux (RHEL) Upstream mehr veröffentlichen zu wollen, sorgte das CentOS Projekt für einiges an Aufregung. Daraus entstanden sind neue RHEL-Abkömmlinge wie AlmaLinux oder Rocky Linux.

CentOS selbst wird weiterhin gepflegt, wirkt allerdings eher wie ein Testumfeld für das kommerzielle Red Hat Enterpise Linux. Konzeptionell werden Pakete, welche in Zukunft in einem RHEL Point Release aufgenommen werden sollen, zunächst in CentOS Stream veröffentlicht. Da die Minor-Versionen dort wegfallen, kann die Distribution als eine Art Rolling-Release angesehen werden. Das Projekt selbst bezeichnet diese Vorgehensweise als continuous-delivery. Vergleichbar ist dies am ehesten mit RHEL nightly builds, welche nicht für die Öffentlichkeit zugänglich sind.

Wie bereits zuvor wird eine CentOS Version von einem Fedora-Release abgeleitet. Im Falle von CentOS Stream 9 wäre dies Fedora 34.

ISO Abbilder stehen für die Architekturen 64-bit x86 (x86_64 v2+), 64-bit ARM (AArch64), IBM Z (s390x Z14+), und IBM POWER (ppc64le POWER9+) zur Verfügung.

Erweitern lässt sich die Distribution unter anderem durch EPEL Repository (Extra Packages for Enterprise Linux). Erfahrungsgemäss ist es um die Multimedia Unterstützung bei CentOS schlecht bestellt, ein Einsatz auf dem Desktop ist wohl aber auch eher unüblich. Bis vor einiger Zeit hat das nux-desktop Projekt diese Lücke geschlossen, welches aber bereits seit CentOS 8 keine Pakete mehr bereitstellt. RPM Fusion bietet auch einen EL-Zweig an, welcher allerdings nur sehr wenige Pakete enthält und aktuell noch nicht für die Version 9 bereitgestellt wird.

Quelle: https://blog.centos.org/2021/12/introducing-centos-stream-9
Download: https://www.centos.org/centos-stream/

7. Dezember 2021

Mozilla hat Firefox 95 und damit das letzte große Firefox-Update dieses Jahres für Windows, Apple macOS und Linux veröffentlicht. Ein besonderer Schwerpunkt lag dabei auf der Sicherheit der Nutzer. Dieser Artikel fasst die wichtigsten Neuerungen zusammen – wie immer auf diesem Blog weit ausführlicher als auf anderen Websites.

Download Mozilla Firefox für Microsoft Windows, Apple macOS und Linux

Bild-im-Bild-Button in Videos kann verschoben werden

Ein Video ansehen und gleichzeitig etwas anderes am Computer machen – Firefox macht’s möglich. Bei Klick auf die entsprechende Schaltfläche wird das jeweilige Video vom Tab losgelöst und erscheint in einem eigenständigen kleinen Fenster. Dieses liegt über allen Anwendungen, d.h. Firefox muss sich nicht im Vordergrund befinden, um das Video zu sehen. Der Benutzer kann beispielsweise seine E-Mails in Thunderbird abrufen und gleichzeitig ein Video auf YouTube ansehen.

Der entsprechende Button in Videos hat sich bisher immer rechts im Video befunden. Über das Kontextmenü ist es jetzt auch möglich, den Button auf die Linke Seite zu verschieben.

@prefers-color-scheme folgt jetzt Firefox-Theme

Mittels @prefers-color-scheme können Websites darauf reagieren, ob der Nutzer ein helles oder ein dunkles Theme nutzt. Bislang folgte Firefox hierfür dem Theme des Betriebssystems. Ab Firefox 95 ist das verwendete Firefox-Theme ausschlaggend.

Wer das alte Verhalten bevorzugt, kann über about:config den Schalter layout.css.prefers-color-scheme.content-override auf den Wert „2“ (ohne Anführungszeichen) setzen. Außerdem wurde eine WebExtension-Schnittstelle implementiert, damit Erweiterungen dies steuern können.

Weitere Verbesserungen der Webplattform

Natürlich unterstützt Firefox auch mit diesem Update wieder weitere Webstandards, darunter das HTML-Attribut inputmode. Eine Übersicht über alle Verbesserungen der Webplattform gibt es wie immer in den MDN web docs.

Performance-Verbesserungen

In Firefox 95 hat Mozilla Verbesserungen bei der Speicherzuweisung vorgenommen. Außerdem wurde die Geschwindigkeit des Ladens von Websites verbessert, indem JavaScript bereits vorab spekulativ kompiliert wird.

Nutzer von macOS profitieren von weiteren Verbesserungen in Firefox 95. So wurde der Stromverbrauch von Software-dekodierten Videos verbessert, vor allem im Vollbild. Dies macht sich unter anderem auch auf Streaming-Seiten wie Amazon Prime und Netflix bemerkbar. Außerdem wurde die CPU-Auslastung in Firefox und WindowServer während der Ereignisverarbeitung reduziert. Auch die Startzeit der Content-Prozesse auf macOS wurde verbessert.

Sicherheit: Seiten-Isolation „Fission“ für mehr Nutzer

Firefox läuft nun schon seit mehreren Jahren mit einer sogenannten Multiprozess-Architektur. Diese unter dem internen Projektnamen Electrolysis, oder auch kurz: e10s, entwickelte Architektur trennt den Browser- von seinen Content-Prozessen, was eine verbesserte Sicherheit durch Sandboxing, Performance sowie Stabilität bringt, da seit dem ein Website-Absturz nicht mehr den kompletten Browser mit abstürzen lässt. Zu den standardmäßig maximal acht Content-Prozessen kommen noch ein paar spezialierte Prozesse wie einer für Firefox-Erweiterungen sowie ein weiterer für den Aufruf lokaler Dateien.

Seit mittlerweile mehr als drei Jahren arbeitet Mozilla unter dem internen Projektnamen Fission an der logischen Weiterentwicklung dieses Konzeptes, einer Seiten-Isolation. Vereinfacht gesagt bedeutet dies, dass damit jeder Tab in einem eigenen Prozess läuft. Genauer wäre zu sagen, dass es einen Prozess pro Ursprung gibt, sprich zwei Tabs von der selben Domain können sich einen Prozess teilen. Auf der anderen Seite kann ein einzelner Tab auch mehrere Prozesse beanspruchen, nämlich dann, wenn auf der Seite Frames von anderen Domains eingebettet sind. Fission schützt auch vor Attacken wie Spectre.

Mit Firefox 94 hat Mozilla die Ausrollung der Seiten-Isolation gestartet. Im Laufe des Firefox 95-Zyklus sollte Fission einen großen Teil der Firefox-Nutzer erreichen.

Sicherheit: RLBox-Sandbox auch für Windows und für weitere Module

Zur Absicherung von Firefox hat Mozilla unterschiedliche Ansätze. Einer ist es, sicherheitsrelevanten Code in der Programmiersprache Rust neu zu schreiben, welche eine ganze Kategorie potentieller Sicherheits-Schwachstellen bereits zur Kompilier-Zeit ausschließt. Ein anderer ist es, Teile des Codes in eigene Prozesse mit weniger Privilegien aufzuteilen. Für alles kommt dies jedoch nicht in Frage. So sei beispielsweise die von Firefox genutzte Font-Rendering-Bibliothek Graphite zu klein für einen eigenen Prozess, da jeder Prozess auch mit einem gewissen Bedarf an System-Ressourcen verbunden ist, außerdem würde ein isolierter Prozess auch nicht verhindern können, dass eine schädliche Schrift-Datei die Seite kompromittiert, welche die Schrift lädt. Eine Neuentwicklung in Rust ist auch keine Option, weil es sich um eine Drittanbieter-Abhängigkeit handelt und das aufwändige Neuschreiben einer solch spezialisierten Komponente auch kein guter Einsatz der begrenzten Ressourcen von Mozilla wäre.

Die Lösung für diese Art von Problem lautet RLBox. Dabei handelt es sich um eine Sandboxing-Technologie, welche von Forschern der University of California, der University of Texas sowie der Stanford University entwickelt worden ist. Damit können bestehende Komponenten in einer WebAssembly-Sandbox ausgeführt werden. Sollte es zu einer Schwachstelle in einer damit isolierten Komponente kommen, selbst wenn es sich dabei um eine sogenannte 0-Day-Schwachstelle handelt, stellt diese keine Gefahr für Firefox-Nutzer dar.

Bereits seit Firefox 74 kommt RLBox in Firefox für Linux zum Einsatz, seit Firefox 75 in Firefox für macOS, jeweils um die Font-Rendering-Bibliothek Graphite zu isolieren. Mit Firefox 95 zieht die Windows-Version von Firefox nach. Außerdem werden auch die Bibliotheken Hunspell (Rechtschreibprüfung) und Ogg (Audio Container-Format) durch RLBox isoliert. Weitere Komponenten werden in zukünftigen Updates folgen. So stehen bereits Expat (XML-Parser) sowie Woff2 (Schriftformat) als zusätzliche Komponenten in Firefox 96 fest.

Sicherheit: Geschlossene Sicherheitslücken

Auch in Firefox 95 wurden wieder mehrere Sicherheitslücken geschlossen. Alleine aus Gründen der Sicherheit ist ein Update auf Firefox 95 daher für alle Nutzer dringend empfohlen.

Sonstige Neuerungen von Firefox 95

Firefox überschreibt auf slack.com nun automatisch den User-Agent, damit Firefox-Nutzern hier mehr Features wie den Huddles zur Verfügung stehen, die Firefox-Nutzern ansonsten vorenthalten werden.

Mit Firefox 85 wurden zahlreiche Verbesserungen an den Lesezeichen vorgenommen, von denen einige hinter dem Schalter browser.toolbars.bookmarks.2h2020 implementiert waren. Mit Firefox 95 existiert dieser Schalter nicht länger und die Verbesserungen sind jetzt für alle Nutzer aktiv.

Natürlich kamen auch in Firefox 95 Fehlerbehebungen, Verbesserungen der Barrierefreiheit sowie sonstige Verbesserungen unter der Haube dazu.

Der Beitrag Mozilla veröffentlicht Firefox 95 erschien zuerst auf soeren-hentzschel.at.

Di, 7. Dezember 2021, Niklas

Das Haiku Projekt hat seinen monatlichen Bericht für den Monat November veröffentlicht. Dieses Mal ist er eher kurz, doch die einzelnen Änderungen sind teilweise sehr bedeutend. Highlights sind NTFS und der Intel Grafiktreiber.

Der Treiber für das Windows-Dateisystem NTFS basiert jetzt auf der neuesten NTFS-3g Version und der Verbindungscode zwischen NTFS-3g und dem Haiku Kernel wurde neu geschrieben. Der alte Verbindungscode stammt noch von BeOS und wurde teilweise für Haiku umgeschrieben. Jetzt ist der Code ähnlich aufgebaut, wie bei anderen Dateisystemen und ist sauberer. Dadurch konnten auch Fehler an anderen Stellen im Treiber gefunden und behoben werden.

Ausserdem wurde der Treiber für das FAT Dateisystem optimiert und einige nicht benötigte Locks entfernt. Weiter wurden alle verbliebenen Nennungen von OpenBeOS im Quellcode zu Haiku geändert und der UDP Socket Code wurde aufgeräumt. Der LGTM Scan wurde aktualisiert und einige Fehler behoben, die er gefunden hat.

Die vielleicht wichtigste Änderung diesen Monat ist die weiter andauernde Arbeit am Grafiktreiber intel_extreme, der für die meisten Intel Grafikeinheiten zuständig ist. Damit werden jetzt auch Chips der Generationen Haswell, Skylake, Coffeelake und Kabylake unterstützt. Es wurden auch viele Probleme mit bereits vorher unterstützten Geräten behoben und der Helligkeitsregler wird nur noch bei eingebauten Displays angezeigt, da die Helligkeit von externen Bildschirmen nicht beeinflusst werden kann.

Es wurden Escape Sequenzen implementiert, mit denen Terminalprogramme die Cursorfarbe auslesen und festlegen können und um andere Farben für verschiedene Farbschemas zu definieren. Ausserdem wurde der Code optimiert, der fehlgeschlagene Paketdownloads wiederholt, sodass beschädigte Downloads nicht mehr den Download der korrekten Datei blockieren.

Des Weiteren wurde CPUID leaf 0x1f implementiert. CPUID ist eine Instruktion, mit der Programme die verfügbaren Funktionen der CPU ermitteln können. Es wird regelmässig aktualisiert, wenn neue Befehlssätze hinzugefügt werden, also muss Haiku diese Änderungen regelmässig übernehmen, um weiterhin die korrekten Funktionen über seine APIs aufzulisten. Ausserdem wurden Informationen über die CPU Frequenz zu cpu_info hinzugefügt. Diese Information war bereits im Kernel, aber wurde nicht an den Userspace weitergegeben.

Für NVMe SSDs wurde die Trim Funktion eingebaut. Mit dem fstrim Befehl kann man die SSD jetzt darüber informieren, wenn bestimmte Sektoren nicht mehr gebraucht werden, sodass diese für eine gleichmässige Abnutzung mitverwendet werden können. Weiter wurde die ConditionVariable Implementation im Kernel überarbeitet, um den Code zu vereinfachen und einen Fehler zu beheben, der manchmal Kernel Panics auslöste.

Die Jamfile Engine wurde jetzt in ein eigenes Repository verschoben. Dabei handelt es sich um ein Build System auf Basis von Jam, mit dem auch Haiku selbst kompiliert wird. Es ist eine Alternative zur Makefile Engine, mit der viel Drittanbietersoftware für Haiku kompiliert wird. Sie ist durch diese Änderung jetzt im Haiku Depot verfügbar und muss nicht mehr von Hand aus dem Haiku Quellcode entnommen werden. Die Jamfile Engine ist hilfreich, wenn man ein Programm mit Jam anstatt mit Make kompilieren will.

Ausserdem wurde damit begonnen, Haiku mit der neueren GCC Version 11 zu kompilieren. Bisher wird GCC Version 8 eingesetzt. Die Umstellung erfordert einige Änderungen am Code, da neue Warnungen entstanden sind und mancher Code nicht mehr erfolgreich kompiliert wird. Es müssen auch einige Stellen debuggt werden, an denen neue Optimierungen in GCC dafür sorgen, dass Code nicht mehr wie vorgesehen funktioniert.

Besonders viel wurde diesen Monat auch an den Portierungen auf andere CPU Architekturen gearbeitet. Am PowerPC Port wurden minimale Fehler behoben, sodass er weiterhin kompiliert werden kann. Der RISC-V Code wurde aufgeräumt und ein paar kleine Fehler wurden darin behoben. Eine funktionierende Version für ARM scheint immer näher zu rücken.

Es gibt viel Fortschritt beim 32Bit ARM Port mit EFI als Bootmethode. Vorherige Versuche, einen ARM Port zu erstellen, nutzten die Bootmethode von Linux, wo der Firmware Bootloader (meistens uboot) nur minimale Schritte für den Startvorgang erledigt und dann die Kontrolle komplett an das Betriebssystem übergibt. Der Linux Kernel ist dafür gemacht, auf diese Art zu funktionieren, aber Haiku ist stärker von der Firmware abhängig, um den Stage 2 Bootloader anzeigen zu können, der ein benutzerfreundliches Boot Menü bietet.

Mit dem alten u-boot System musste hardwarespezifischer Code für jedes neue ARM Gerät geschrieben werden und der Bootloader enthielt sehr viel hardwarespezifischen Code. EFI löst das Problem. Bei der EFI Bootmethode werden Befehle an u-boot oder andere EFI Implementierungen gesendet und diese erledigen die hardwarespezifischen Aufgaben. Damit kann auch der Code der x86 und RISC-V Ports wiederverwendet werden, die auf die gleiche Art starten.

Nachdem die Bootloader Probleme behoben sind, wird es jetzt viel einfacher, die frühen Schritte des Kernelstarts zu untersuchen, was schon zu vielen Verbesserungen beim MMU Treiber und der FDT Hardware Discovery geführt hat.

Auch am 64Bit ARM (aarch64) Port wurde gearbeitet. Hier wurden Probleme im Code der Math Bibliothek behoben und einige Compiler Flags optimiert.

Ganz neu wird jetzt auch an einem 32Bit x86 EFI Bootloader gearbeitet. Bis jetzt konnte nur die 64Bit Version mit EFI starten und brauchte dazu auch ein 64Bit EFI BIOS, während die 32Bit x86 Version von Haiku nur im Legacy BIOS Modus gestartet werden konnte. Einige Geräte haben aber keine Legacy Boot Option mehr, obwohl sie noch mit 32Bit CPU ausgestattet sind oder eine 64Bit CPU, aber nur ein 32Bit EFI haben. Diese Geräte konnten bislang nicht mit Haiku genutzt werden, der neue 32Bit EFI Bootloader wird es aber demnächst möglich machen.

Quelle: https://www.haiku-os.org/blog/pulkomandy/2021-12-02-haiku_activity_report_november_2021/

6. Dezember 2021

Mo, 6. Dezember 2021, Ralf Hersel

EndeavourOS ist eine rollende Linux-Distribution, die auf Arch Linux basiert. Das Projekt bietet eine einfach einzurichtende und vorkonfigurierte Desktop-Umgebung auf der Basis von Arch. Bei EndeavourOS gibt es sowohl Offline- als auch Online-Installationsoptionen. Der Offline-Installer, Calamares, verwendet standardmässig den Xfce-Desktop. Das Online-Installationsprogramm kann optionale Softwarekomponenten installieren, darunter die meisten gängigen Desktop-Umgebungen.

Was ist neu in EndeavourOS Atlantis? Version 21.4 verwendet den Linux Kernel 5.15 (LTS). Atlantis bleibt bei Xfce 4.16 als Standard-Desktop-Umgebung bei der Live-Sitzung und fügt einige Verbesserungen und neue Ergänzungen zu den EndeavourOS-Anwendungen/Tools hinzu. So gibt es beispielsweise eine neue Sicherheitsüberprüfung für Benutzer von NVIDIA-GPUs und Kernel-Updates, um Boot-Fehler nach einem Update zu verhindern.

Zu den weiteren Neuerungen gehören:

  • Das Werkzeug eos-apps-info ist nun standardmässig installiert
  • Die Welcome-App hat eine neue Schaltfläche erhalten, die den Benutzer zu einer Seite mit weiteren Informationen über die vorinstallierte Desktop-Umgebung führt
  • Das Tool eos-apps-info-helper wurde aktualisiert, um Informationen über weitere Apps anzuzeigen
  • eos-update-notifier hat ein neues und verbessertes Zeitplan-Konfigurationsfenster erhalten
  • paccache-service-manager ermöglicht es dem Benutzer nun, den Cache von deinstallierten Paketen zu löschen.

Ebenfalls verbessert wurde das grafische Installationsprogramm Calamares, das die Installation von Arch Linux für Neueinsteiger erleichtert. Der Installer unterstützt jetzt die gleichzeitige Installation der Xfce-Desktop-Umgebung und des i3-Fenstermanagers, fügt zstd für Btrfs für die Installation auf SSD- und HDD-Laufwerken hinzu, aktiviert standardmässig fstrim.timer, verwendet zufällige EFI-Pfadbenennungen, unterstützt das Lesen der Ausgabe von pacman-Aktionen, aktiviert standardmässig DRM-Modi für NVIDIA-GPU-Benutzer und ermöglicht es Benutzern, Installationsprotokolle an die Entwickler zu senden.

Auswahl der Desktop-Umgebungen während der Installation

Weitere interessante Änderungen im Calamares-Installationsprogramm sind die Unterstützung für EndeavourOS-Repos und die Welcome-App, die standardmässig eine Verbindung zu GitLab herstellt, die Entfernung von GitHub aus der EndeavourOS-Spiegelliste und eine neue Methode für die Installation einer der EndeavourOS Community-Editionen.

"Jetzt wählt man zuerst die Community-Edition aus, die ein festes Einstellungspaket ist, das nicht verändert werden kann, um fehlgeschlagene Installationen zu vermeiden, und gelangt dann zum Basispaketmodul, wo man bestimmte Pakete abwählen kann, wenn man das möchte", heisst es in der Ankündigung.

Neben anderen Änderungen verbessert EndeavourOS Atlantis Legacy Boot, führt die Möglichkeit für Benutzer ein, ihre eigenen Bash-Befehle zu schreiben, wird mit installiertem OS Prober ausgeliefert. Atlantis wird mit installiertem PipeWire für Audio ausgeliefert, verbessert die Unterstützung für bestimmte PCIe-basierte M.2-Laufwerke, ersetzt den Treiber r8168 durch r8169 und fügt mehrere neue Hintergrundbilder hinzu.

EndeavourOS Atlantis kann von der Webseite des Projekts herunterladen und installiert werden. Weitere Details zur neuen Version finden sich in den Release Notes:

Quelle: https://endeavouros.com/news/the-atlantis-release-is-in-orbit/

Dieser Blogpost enthält meine Antwort auf den Meinungsartikel von Niklas auf GNU/Linux.ch: „Verliert die Free-Software-Community ihre Werte?“

Niklas weist in seinem Artikel auf den Umstand hin, dass zur Bereitstellung von, Verteilung von, Beteiligung an und Diskussion um Freie-Software-Projekte vermehrt Werkzeuge genutzt werden, welche einer proprietären Lizenz unterliegen. Er kritisiert, dass dies die Freiheit Nr. 3 einschränkt:

Freiheit 3: Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gemeinschaft davon profitiert.

https://gnulinux.ch/verliert-die-free-software-community-ihre-werte

Aus Niklas‘ Sicht werden durch die Verwendung proprietärer Werkzeuge/Plattformen wie z.B. GitHub und Discord Nutzer davon abgehalten bzw. daran gehindert, sich an der Entwicklung freier Software zu beteiligen. Niklas schließt seinen Artikel mit folgenden Fragen, die ich in diesem Beitrag gern beantworten möchte.

… Habt ihr selbst Projekte? Werdet ihr etwas verändern? Beteiligt ihr euch an Projekten? Werdet ihr eure Bedenken weitergeben? War der Artikel hilfreich?…

https://gnulinux.ch/verliert-die-free-software-community-ihre-werte

Ja, ich habe einige Projekte. Einige habe ich auf GitHub veröffentlicht. Andere werden in der GitLab-Instanz der Universität Bielefeld gepflegt. Damit verwende auch ich ein proprietäres Werkzeug für meine eigenen Projekte.

Darüber hinaus nutze ich GitHub auch, um mich an diversen anderen Projekten zu beteiligen. Und es gefällt mir, weil es mir die (Mit-)Arbeit und Beteiligung so einfach macht. Hier sind viele Projekte, die mich interessieren. Hier suchen viele Nutzer nach interessanten Projekten. Mit dieser Plattform erreiche ich mit meinen Projekten viele potenzielle Nutzer. Ich finde es praktisch, den Issue-Tracker und die Verwaltung der Pull Requests dabei zu haben. Und nicht zuletzt ist das Hosting meiner Projekte hier kostenfrei.

Dass es sich bei GitHub nicht um Freie Software handelt, hat mich bisher nicht gestört. Ich habe allerdings auch noch nicht bewusst darüber nachgedacht.

Da ich IRC nicht mag, es mich eher stört, wenn jedes Projekt sein eigenes Forum betreibt, für das ich mich erst registrieren muss, finde ich es praktisch, dass ich mich mit einem GitHub-Account an so vielen Projekten beteiligen und mich über den Issue-Tracker mit ihnen austauschen kann. Daneben schätze ich noch, wenn die Möglichkeit besteht, mit einem Projekt via E-Mail in Kontakt zu treten, da dies für mich persönlich die geringste Hürde darstellt.

Allerdings kann ich Niklas auch gut folgen. Vermutlich würde ich mich nicht bei Discord registrieren, um mich an einem Projekt beteiligen zu können. Dass ich mit einigen Projekten ausschließlich über Google-Groups kommunizieren kann, finde ich ebenfalls doof, ist hierfür doch ein Google-Konto Voraussetzung.

Ich besitze auch noch einige Zugänge zum Bugzilla von Red Hat (https://bugzilla.redhat.com) und bin dort hin und wieder aktiv. Bugzilla steht unter einer Open-Source-Lizenz. Der Bugtracker wird in diesem Fall von einem profitorientierten Unternehmen betrieben (Red Hat). Macht es das schon besser als GitHub, eine proprietäre Anwendung in den Händen eines profitorientierten Unternehmens (Microsoft)? Ich weiß es nicht.

In beiden Fällen (Red Hat Bugzilla und GitHub) finde ich persönlich meine Freiheit Nr. 3 nicht beschränkt. Im Gegenteil. Empfinde ich es doch als Erleichterung, mich an Projekten beteiligen zu können.

Niklas hat in seinem Artikel Codeberg erwähnt, welches ich bisher noch nicht kannte. Es handelt sich dabei um eine Kollaborationsplattform Git-Hosting für Freie- und Open-Source-Software. Auf den ersten Blick bietet das Projekt Codeverwaltung, Issue-Tracker und Pull-Request-Verwaltung. Alles unter einer freien Lizenz. Betrieben wird die Plattform vom gemeinnützigen Verein Codeberg e.V., dessen Satzung hier eingesehen werden kann. Die Idee und Motivation des Vereins gefällt mir und ich halte diese für unterstützenswert.

Codeberg bietet scheinbar die Funktionalität, welche ich für meine Projekte benötige. Werde ich jetzt etwas verändern? Nun, ich kann mir gut vorstellen, mein nächstes Projekt auf Codeberg zu hosten. Erst wenn ich die Plattform einige Zeit selbst genutzt habe, kann ich mir ein Urteil darüber bilden.

An Niklas gerichtet: Ja, ich finde deinen Artikel hilfreich. Er regt zum Nachdenken an und ich habe dadurch eine Plattform kennengelernt, die ich bisher noch nicht kannte und welche auf den ersten Blick einen guten Eindruck macht.

Nun habe ich noch eine Frage an meine Leser hier. Wenn ein Projekt seinen Code nicht auf GitHub hostet, stellt dies für euch eine Hürde dar, die Software zu verwenden oder euch am Projekt zu beteiligen? Oder senkt dies eure Hemmschwelle sogar?