Es gibt mal wieder Schwachstellen in X.Org. Genauer gesagt wurden mal wieder neue Schwachstellen entdeckt. Die Software steckt sicherlich voll von noch mehr Problemen und ihre vollständige Ablösung ist mehr als überfällig.

Leider zieht sich die Wayland-Transformation länger hin, als das vor ein paar Jahren alle vermutet hatten. GNOME war zuerst Wayland-tauglich und seit diesem Jahr funktioniert auch KDE Plasma mehr oder minder gut mit Wayland. Alle anderen Desktopumgebungen und Fenstermanager sind noch nicht so weit oder werden vielleicht nie so weit sein. Hier wird sich vermutlich die Spreu vom Weizen trennen, wenn die Distributionen nicht mehr bereit sind X.Org zu pflegen. Die Linux-Welt muss also noch einige Zeit mit X.Org leben müssen.

Es tut mir fast schon ein wenig leid, dass ich schon wieder was Negatives über Debian schreiben muss. Die Updateprobleme bei Firefox reichen eigentlich schon. Leider sind die Fakten wie sie sind:

Es geht um folgende vier Sicherheitslücken: 2021-4008, 2021-4009, 2021-4010, 2021-4011. Diese wurden durch die Zero Day Initiative von Trend Micro gefunden.

Öffentlich bekannt sind die Lücken seit dem 14. Dezember. Die Distributionen wurden allerdings bereits vorab informiert, um schnell Sicherheitsupdates bereitstellen zu können. Entsprechende Patches lagen Upstream vor. Das Vorgehen ist somit ideal und die notwendige Eigenleistung der Maintainer überschaubar. Ein entsprechender Bugreport für CVE 2021-4008 datiert im SUSE Bugzilla auf den 24. November. Das Changelog bei SLE/openSUSE Leap verrät zudem, dass die Lücke bereits am 25. November geschlossen wurde.

Pünktlich am 14. Dezember verteilte SUSE die Updates für die Lücken. Das gilt ebenso für Ubuntu, wo Canonical ebenfalls am 14. Dezember pünktlich Updates verteilte. Fedora war ein bisschen langsamer, die Updates kamen erst vor einigen Stunden in die beiden unterstützen Varianten Fedora 34 und 35. Den Status für RHEL konnte ich nicht herausfinden, gehe aber davon aus, dass dieser mindestens analog zu Fedora ist. Bei Debian ist hingegen aktuell immer noch Schweigen im Walde. Lediglich für Sid und Testing hat man Updates bereits verteilt.

Ich möchte hier jetzt nicht schon wieder zum Rundumschlag ausholen, weil ich mit Sicherheit keine Kampagne gegen Debian fahren möchte. Fakt ist, dass sich Debian-Anwender die Entwicklung ganz genau ansehen sollten. Für mich ist aktuell Debian für den Desktop nur noch unter Vorbehalt empfehlenswert. Vorlieben bei Distributionen, lang gepflegte Distro-Wars, Kritik an irgendwelchen Communitys etc. sind nett für die eigene Entscheidungsfindung, aber bei offenen Sicherheitslücken hört der Spaß auf.

Der Artikel Debian – Verzögerung bei Sicherheitsaktualisierungen erschien zuerst auf [Mer]Curius

Sa 18. Dezember 2021, Norbert Rüthers

Nur eine kurze Mitteilung. Bereits in einem anderen Artikel wurde hier die neue Version 2021-4 von Kali Linux vorgestellt

Bisher lief Kali Linux auf dem Raspberry nur mit SD-Karte. Das hat sich mit der neuesten Version geändert

Kali Linux 2021-4 ist jetzt auch auf einem Raspberry Pi mit HDD oder SSD nutzbar. Man kann das Image von Kali einfach z.B. mit Balena Etcher auf die Festplatte übertragen. Beim ersten Start wird die Grösse der Festplatte automatisch angepasst, was bei grossen Festplatten ein paar Minuten dauern kann.

Die deutsche Sprachanpassung kann mit folgendem Kommando auf dem Terminal erfolgen

dpkg-reconfigure locales

Das Tastaturlayout lässt sich in den normalen Systemeinstellungen anpassen. Beim Test auf einem Raspberry Pi 4 mit 4 GB RAM und SSD ist ein ziemlicher Performance-Schub im Vergleich zur SD-Karte spürbar.

Quelle: https://www.kali.org/

Eine konstruktive Auseinandersetzung lebt davon, dass man grundsätzlich vom selben spricht und dasselbe unter den verwendeten Begriffen versteht. Das war bei Linux immer klar, weil sie Systeme sehr uniform waren. Das ändert sich nun.

Linux-Systeme waren in der Vergangenheit relativ gleichförmig und in den letzten Jahren gab es meiner Meinung nach sogar einen Trend zu noch mehr Gleichförmigkeit. Das ändert sich in einigen Teilen des Linux-Ökosystems nun wieder. Man denke nur an Fedora Silverblue oder openeSUSE MicroOS. Das sind keine rein experimentellen Projekte, sondern bei Fedora ist man sich sicher, dass hier die Zukunft liegt. Durch diese Entwicklung entsteht eine Chance, weil das ausufernde Distributionssystem nur bei wirklichen Alternativen Sinn macht und nicht, wenn man praktisch 100 Mal das Gleiche bekommt.

Es führt aber auch zu Problemen. Das konnte man jüngst beobachten, als sich verschiedene Personen mal wieder über das Für und Wider von Flatpak stritten. Den Anfang machte der ausufernde Artikel „Flatpak Is Not the Future“ auf den es verschiedene Repliken gab. Besonders hervorheben möchte ich „On Flatpak disk usage and deduplication„. In der Sache mag ich mich daran nicht mehr beteiligen, weil ich dazu in einem Artikel mal alles zusammen geschrieben habe, was zum Thema Flatpak, Snap und Paketverwaltung zu sagen ist.

Man kann aber bei der Argumentation sehen, dass es zunehmend schwieriger wird, sich auf eine gemeinsame Diskussionsgrundlage zu verständigen, weil die Voraussetzungen stark abweichen. Ich möchte das an zwei überzeichneten „Szenarien“ demonstrieren.

Die Befürworter moderner Paketformate wie Snap und Flatpak nutzen – und setzen damit auch als Diskussionsgrundlage voraus – moderne Systeme. Diese Systeme sind auf der Höhe dessen, was die Linux-Entwicklung in den letzten Jahren hervorgebracht hat. Ein aktueller Kernel wird begleitet von systemd, das zentrale Aufgaben im System effizient erledigt. Als Dateisystem nutzt man moderne Systeme wie Btrfs mit State-of-the-Art Funktionen wie z. B. Deduplizierung und flexible Subvolumes anstelle von Legacy-Partitionierungsschemata. Der Speicherbedarf ist bei solchen Systemen keine objektive Größe mehr und man kann flexibel auf Änderungen reagieren. Anstelle in dogmatischen Konzepten, denkt man in gewünschten Funktionen. Ein Beispiel dafür ist der Versuch, Betriebssystemupdates resistenter gegen Fehler zu machen, indem man Rollback-Methoden implementiert und dafür mit der Unix-Dateisystemstruktur bricht. Im openSUSE-Umfeld arbeitet man daran seit Jahren. Mit Fedora Silverblues rpm-ostree und read-only Dateisystemen hat man hier ganz neue Maßstäbe gesetzt. Updates werden vereinfacht gesagt als Images neben der bisherigen Installation eingerichtet und durch einen Neustart aktiviert. Das funktioniert nur, wenn man die Anwendungsinstallation vom Betriebssystem löst, weil der Anwender sonst andauernd neustarten müsste. Diese Entwicklungen bilden die Grundlage für weiterführende Überlegungen, wie man Linux noch sicherer machen könnte. Hier orientiert man sich an dem, was andere Hersteller in ihre Betriebssysteme implementieren. Entwickler Anwender solcher Systeme nutzen dann zudem meist noch einen modernen Desktop wie Plasma oder GNOME mit Wayland, weil sie X.Org als Sicheitsproblem wahrnehmen – aber das nur als Nebenaspekt.

Die Kritiker der Entwicklung gehen von gänzlich anderen Voraussetzungen aus. Konzepte und Grundlagen mit jahrzehntelanger Gültigkeit wie z. B. „Unix-Philosophie“ oder „KISS-Prinzip“ sind für sie handlungsleitend. Sie waren mit der Linux-Entwicklung zu einem gewissen Stichtag zufrieden. Das kann je nach Person variieren, aber liegt bei den meisten irgendwo um die Jahre 2008 bis 2014 herum. Dadurch ergibt sich ein völlig anderes Problem- bzw. Desideratbewusstsein. Weiterentwicklung bedeutet für sie eine evolutionäre Fortschreibung des Status quo. Die integrierte Paketverwaltung ist für sie die das Ergebnis von 20 Jahren Entwicklungsarbeit. Objektiv gemessene Effizienz und kleinteilige Patches sind für sie der Maßstab des Erfolgs. Der ganze Container-Hype war ihnen schon immer suspekt und wurde höchstens am Rande verfolgt. Objektiv messen können sie Sachen wie Speicherverbrauch, weil sie Entwicklungen wie Btrfs immer als instabil abgelehnt haben, das letzte Mal von ext3 auf ext4 migriert sind und deshalb viele Funktionen nur vom Hörensagen kennen. Subvolumes brauchen sie nicht, weil LVM ihnen genug Kontrolle gibt und sie keinen Mehrwert hinter flexibleren Lösungen sehen. Read-only Systeme sind für sie moderner Schnickschnack von Apple und Googles Smartphones, der ihnen Eingriffsmöglichkeiten und Kontrolle nimmt. Das gilt ebenfalls für Sachen wie Secure Boot oder TPM und darauf aufbauende Konzepte. Die Adaption scheitert hier schon, weil man der systemd-Entwicklung skeptisch gegenüber steht und es höchstens als Init-System nutzt und bei den anderen Bestandteilen auf spezialisierte Alternativen zurückgreift. Selbst die vorbereitenden Maßnahmen zu Schnappschüssen, wie z. B. der usr-merge sind für sie eigentlich Verrat an Unix-Prinzipien und wurden widerwillig mitgetragen. Probleme mit der Paketverwaltung und Upgrades hatten sie ja schließlich nie. Die Sicherheit von Linux ist unübertroffen, das zeigen schließlich die Fakten und ständigen Sicherheitslücken bei Windows. Abgerundet wird dieses Bild durch einen konservativen Desktop wie z. B. Xfce oder MATE und den X-Server, da sie keinesfalls auf wichtige Linux-Errungenschaften wie Netzwerktransparenz verzichten möchten.

Diese beiden Gruppen eint mit jedem Jahr weniger – abgesehen davon, dass beide glauben, sie würden Linux verwenden. Diese Auseinanderentwicklung ist der Grund für wenig zielführende Debatten wie sie oben beispielhaft verlinkt sind. Die eine Seite sagt, Flatpak braucht viel Speicherplatz, weil ein Flatpak so und soviel MB groß ist und ein klassisches Paket weniger hat. Außerdem würden Flatpaks außerhalb der Unix-Struktur abgelegt und die Partitionen wären an bestimmten Stellen dann zu klein. Die andere Seite sagt, das stimmt gar nicht, weil der Unterschied dank Deduplizierung von Runtimes marginal wäre und flexible Strukturen sich jederzeit an neue Erfordernisse anpassen lassen.

Beide Seiten haben auf ihre Art recht. Die Grundlagen, von denen man ausgeht, divergieren im Extremfall inzwischen so stark, das man eigentlich keine gemeinsame Diskussionsgrundlage mehr hat. Vielleicht wäre das auch einfach die Einsicht, an der man eine Diskussion beenden kann.

Der Artikel Das Problem: Wir reden nicht mehr vom selben Linux erschien zuerst auf [Mer]Curius

Mozilla hat mit Firefox 95.0.1 ein Update außer der Reihe für seinen Desktop-Browser veröffentlicht.

Download Mozilla Firefox 95.0.1

Mit dem Update auf Firefox 95.0.1 behebt Mozilla das Problem, dass Firefox-Nutzer diverse Microsoft-Websites nicht länger aufrufen konnten und nur den Fehlercode MOZILLA_PKIX_ERROR_OCSP_RESPONSE_FOR_CERT_MISSING erhalten hatten, nachdem Microsoft eine serverseitige Konfigurationsänderung (OCSP-Stapling mit SHA-256-Hashes) durchgeführt hat, die von Mozillas NSS-Bibliothek so bisher nicht unterstützt worden war.

Behoben wurde auch eine mögliche Absturzursache in Zusammenhang mit WebRender unter Linux/X11 sowie eine mögliche Absturzursache beim Beenden von Firefox unter Windows.

Der Vergangenheit angehören sollten auch Probleme mit dem Website-Kontrast für manche Linux-Nutzer, welche den Dark Mode auf Betriebssystem-Ebene aktiviert haben.

Der seit Firefox 95.0 bei Verwendung von Slack überschriebene User-Agent wird nicht länger überschrieben, nachdem Slack seit diesem Montag auch für Firefox-Nutzer das Huddles-Feature unterstützt.

Außerden wurden mehrere Verbesserungen in Zusammenhang mit Remote-Einstellungen vorgenommen, welche insbesondere Nutzer von Linux Mint betreffen, wo Suchmaschinen-Einstellungen bei einem Upgrade nicht ordnungsgemäß aktualisiert worden waren.

Schließlich wurde noch behoben, dass die Einstellungen für manche Nutzer einen neuen Reiter anzeigten, der noch nicht sichtbar sein sollte.

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

Mi, 15. Dezember 2021, Niklas

Lakka ist keine gewöhnliche Linux Distribution. Sie ist vollkommen auf Gaming ausgerichtet, und zwar auf sehr alte Spiele. Sie nutzt LibRetro und RetroArch als Emulator für eine Vielzahl alter Spielekonsolen. Die Emulatoren werden alle direkt mitgeliefert, nur die Spiele muss man selbst haben.

Lakka basiert auf der Distribution LibreELEC. Es ist sehr leichtgewichtig, das GZip komprimierte Image ist nur gut 600 MB gross. Lakka kann auf einer Vielzahl von Einplatinencomputern genutzt werden, wie zum Beispiel den meisten Versionen des beliebten Raspberry Pi. Auch eine x86 Version ist verfügbar. Ich teste es wie immer auf meinem Lenovo 3000 N200 Laptop.

Das System startet innerhalb von wenigen Sekunden vom USB-Stick in ein Live System. Alternativ kann es auch auf der Festplatte installier werden. Das User-Interface ist an die Playstation angelehnt. Es kann komplett mit einem Controller bedient werden, Maus und Tastatur sind nicht notwendig. Wer keinen Controller hat, kann allerdings auch eine Tastatur verwenden. Die Maus hat auf dem Betriebssystem keine Funktion.

Da Lakka keine Spiele mitbringt, ist es sinnvoll, zunächst die WLAN-Verbindung einzurichten. Man hat dann Zugriff auf den Online Updater, mit dem man im Bereich Content Downloader ein paar ausgewählte Spiele herunterladen kann. Bei meinem Test haben leider die wenigsten davon funktioniert. Die Verzeichnisstrukturen sind ausserdem sehr unübersichtlich, Lakka zeigt nicht nur die ausführbare Datei des Spiels, sondern alle zugehörigen Dateien.

Eine wesentlich grössere Auswahl an Spielen bieten spezielle Downloadportale für Retro Spiele, wie beispielsweise Retrostic. Das hier heruntergeladene Super Mario Kart funktioniert bei meinem Test auf Lakka einwandfrei. Da Lakka keinen eigenen Browser mitbringt, muss man die Spiele jedoch über einen anderen Computer herunterladen und per Samba auf die Lakka Installation übertragen. Der Samba Server von Lakka ist standardmässig aktiviert und wurde von meinem FreeBSD Computer ohne Weiteres gefunden.

Wer noch originale Spiel DVDs von früher hat, braucht diese nur ins DVD-Laufwerk des Lakka Computers zu legen und kann sie direkt starten oder wahlweise auch auf die Festplatte kopieren, um nicht immer die DVD zu brauchen. Diese Funktion konnte ich mangels DVDs nicht testen.

Auch Multiplayer Spiele sind mit Lakka kein Problem, es können bis zu 5 Controller angeschlossen werden, vorausgesetzt das verwendete Gerät hat so viele Anschlüsse. Über die Funktion Netplay können ausserdem mehrere Lakka Geräte miteinander verbunden werden, sodass Multiplayer Spiele auch aus der Ferne möglich sind. Eine Lakka Installation ist dabei der Server, andere können sich als Client verbinden.

Wer sich lieber online mit Spielern aus aller Welt messen möchte, findet bestimmt die Funktion Achievements interessant, die eine Integration von RetroAchievements bietet. Auf der Seite können Achievements in einer Vielzahl von Retro Spielen gesammelt werden, es gibt fast 200000 registrierte Spieler, eine Teilnahme ist kostenlos.

Fazit: Lakka bietet alles, was sich Fans von Retro Konsolen nur wünschen können und noch viel mehr, als die alten Originale konnten. Es wirkt ausgereift und ist einfach zu bedienen. Mit meinem Laptop habe ich allerdings mangels Alternativen ein denkbar schlechtes Testgerät gewählt - viel mehr Spass macht es am grossen Fernseher und mit richtigen Controllern, vor allem wenn man zusammen mit Freunden oder Familie zocken will.

Mi, 15. Dezember 2021, Lioh Möller

Trisquel wird von einigen Anwendern auch liebevoll als die Linux-Distribution der Herzen bezeichnet. Grund dafür ist, dass sie vollständig auf Freier Software basiert und den fsf Richtlinien für Freie GNU/Linux-Verteilungen entspricht. Damit einher geht allerdings, dass die eigene Hardware möglicherweise nicht lauffähig ist, sofern für deren Betrieb unfreie Treiber benötigt werden. Dies ist beispielsweise bei vielen W-LAN-Adaptern der Fall.

Darüber hinaus basiert Trisquel in der Regel auf einer älteren Ubuntu Version. So kommt bei der aktuellen stabilen Version Trisquel 9.0 "Etiona" beispielsweise Ubuntu 18.04 als Basis zum Einsatz.

Nun haben die Entwickler erste Pre-Release-Versionen von Trisquel 10.0 zum Testen bereitgestellt, welche auf der aktuellen Ubuntu LTS Version 20.04 basieren.

Ein Download ist aufgrund von Einschränkungen des Spiegelservers beispielsweise mithilfe von lftp möglich:

sudo apt install lftp

lftp -c 'set net:idle 10
         set net:max-retries 0
         set net:reconnect-interval-base 3
         set net:reconnect-interval-max 3
         pget -n 10 -c "http://cdbuilds.trisquel.org/trisquel_10.0_amd64.iso"'

Alternativ zur Hauptversion, bei der MATE als Desktopumgebung genutzt wird, wird eine Variante mit KDE Plasma namens Triskel angeboten. Für ältere Rechner eignet sich Trisquel lite bei der LXDE zum Einsatz kommt. Eine vollständige Liste aller verfügbaren Versionen ist auf dem Spiegelserver einsehbar.

Neben den bereits in Ubuntu 20.04 enthaltenen Aktualisierungen wie LibreOffice 7.1, bietet Trisquel 10.0 eine befreite Variante des Firefox Browsers mit dem Namen Abrowser an. Letztere wird aktuell in Version 95.0 mitgeliefert und regelmässig aktualisiert. Die Entwickler sind über Feedback dankbar.

Debian und Firefox ist momentan ein heißes Eisen. Eine Distribution, die sich Sicherheit und Stabilität auf die Fahnen schreibt und dann wochenlang keine Firefox-Updates verteilen kann, steht zurecht im Zentrum der Kritik. Zumindest dieses Problem scheint bald gelöst.

Normalerweise ist so etwas keinen Blogartikel wert, aber da ich mich zu dem Problem hier bereits zwei Mal geäußert hatte, gehört es zur Korrektheit auch die weitere Entwicklung zu spiegeln.

Ausgehend von der Phoronix-Meldung hatte ich hier wie auch andere berichtet, dass eine Inkompatibilität mit Mesa das Problem wäre. Dem scheint nicht so gewesen zu sein. Grund war vielmehr ein Problem mit dem Rust-Compiler, was unter anderem in diesem Bug nachzulesen ist. Diesen Compiler braucht aber nur der Maintainer, der Anwender benötigt für die Nutzung von Firefox keinen Rust-Compiler.

Es geht dabei also um ein eher „akademisches“ Problem. Ohne die Verfügbarkeit unter Debian Stable würde man allerdings keine „Reproducible Builds“ erreichen. Ich bin grundsätzlich ein Befürworter von reproduzierbaren Builds, denn wie soll man sonst sicher sein, dass die Binärprogramme wirklich dem freien Quellcode entsprechen und nicht davon abweichen. Das Problem hat uns schließlich bei TrueCrypt viele Jahre begleitet, bevor es „gelöst“ werden konnte. Reproduzierbare Builds als eher theoretisches Problem so hoch zu gewichten, dass dadurch alle Stable-Nutzer wochenlang auf ein sicherheitskritisches Firefox-Update warten mussten, ist aber eine andere Hausnummer.

Meine ursprüngliche Bewertung, dass es sich hier um ein originäres Debian-Problem handelt, gilt daher immer noch. Denn Debian hat anscheinend wochenlang mit sich gerungen, ob es für ein Programm eine Ausnahme machen möchte oder eine extra Abhängigkeit nur für Firefox in die stabile Distribution einziehen will. Zumal das Problem ja auch nur entstand, weil man zum Release ein relativ altes Paket rustc auslieferte. Zur Erinnerung: Die in Stable enthaltene Variante war aus dem November 2020.

Außerdem löst das Update von Firefox nur ein Problem und befreit die Anwender nicht von den unsicheren anderen Programmen, wie z. B. Chromium. Die Probleme sind und bleiben eben doch größer als Firefox.

Der Artikel Debian und Firefox – Nicht Mesa sondern Rust als Problem erschien zuerst auf [Mer]Curius

GrapheneOS ist nach der Installation ein sehr rudimentäres Betriebssystem. Es gibt wirklich nur das Android-Basissystem und ein paar wenige Apps: Telefon, SMS, Kontakte, Dateien, Kamera, Galerie, Browser. Zum Glück steht mit F-Droid ein Store mit freier Software zur Verfügung.

Die Installation wurde im letzten Teil der Serie schon kurz angerissen:

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.

F-Droid

F-Droid ist nicht der optisch hübscheste Store, aber funktional. Ähnlich wie bei Linux stehen hinter den dortigen Angeboten Maintainer und nicht die Entwickler der Software selbst. Es kann deshalb zwischen einer Versionsänderung upstream und dem Erscheinen im F-Droid Store einige Zeit vergehen.

• 

• 

Es gibt eine Startseite, auf der ausgewählte Apps präsentiert werden. Klickt man auf eine dieser Apps, erscheint die auch von anderen Systemen bekannte Übersicht mit einer Beschreibung, Screenshots, weiterführenden Informationen und ggf. einem Änderungsprotokoll sowie der Schaltfläche, um die App zu installieren.

• 

• 

F-Droid benachrichtigt über anstehende Updates. Die GrapheneOS-Einbindung von F-Droid mit Benutzerrechten macht eine automatische Installation leider unmöglich. Stattdessen erfolgt die übliche Systemabfrage, um jede App einzeln zu aktualisieren.

F-Droid Apps

Die rudimentäre GrapheneOS-Ausstattung macht es nötig, einige Apps zu installieren. Im Folgenden sollen einige Vorschläge gemacht werden. Es gibt aber sicherlich noch viele weitere hervorragende Apps und sicher auch tolle Alternativen zu den unten genannten.

Kategorie	App
Browser	Vanadium (vorinstalliert); Bromite (zusätzliche Paketquelle)
Browser	Tor Browser (zusätzliche Paketquelle The Guardian Project)
RSS	Readrops
Mail	K-9 Mail
Messenger	Signal FOSS (Fork von Signal, zusätzliche Paketquelle)
PGP-Verschlüsselung	OpenKeychain
Podcast	Antennapod
Sicherheit	Blokada 5
Kontakt- / Kalendersnychronisation	DAVx5
Internetkalender abonnieren	ICSx5
Wetter	Forecastie
OTP	FreeOTP+
PC-Integration	KDE Connect (nur bei KDE Plasma und GNOME möglich)
Passwörter	KeePassDX
PDF-Dokumente	PDF (vorintalliert)
Kamera	Kamera (vorinstalliert)
Karte & Navigation	OsmAnd; Organic Maps
Aufgaben	Tasks
Kalender	Etar
Nahverkehr	Transportr
Notizen	Notally
Multimedia	VLC
Sonstiges	Covpass, Corona Contact Tracing Germany

Im Großen und Ganzen bin ich mit den Apps sehr zufrieden. Lediglich zu OsmAnd hätte ich gerne eine Alternative. Natürlich hat die App einen tollen Funktionsumfang und OSM ist eines der Vorzeigeprojekte der kollaborativ arbeitenden freien Gemeinschaft. Die GUI von OsmAnd ist nur wirklich unhandlich und die Suchfunktion treibt mich regelmäßig zur Verzweiflung. Nachtrag: Alternative dank Hinweis auf Organic Maps gefunden.

Ich kann inzwischen tatsächlich einen Großteil meines Bedarfs über Open Source Apps decken. Lediglich den DB Navigator, WhatsApp, Signal, Threema und das PhotoTAN meiner Bank beziehe ich nicht über F-Droid. Das ist inzwischen der Sockel, der sich vermutlich nicht mehr reduzieren lässt. Besonders ärgerlich finde ich das bei Signal.

Der Artikel GrapheneOS – Eine Sammlung von F-Droid Apps erschien zuerst auf [Mer]Curius

Wenn man einen Anwendungs-Dienst betreibt, welcher nur für ein bestimmtes Release von Red Hat Enterprise Linux wie bspw. RHEL 8.4 freigegeben ist, gilt es effektiv zu verhindern, dass bei Updates Pakete installiert werden, die zu einem folgenden Release wie z.B. RHEL 8.5 gehören. Andernfalls verliert man bestenfalls die Unterstützung vonseiten des Herstellers der Anwendung. Im schlimmsten Fall ist die Anwendung nicht mehr lauffähig und man muss das Upade zurückrollen.

Hinweis von Steffen Frömer (Senior Technical Account Manager bei Red Hat): Um Updates für ein spezifisches Minorrelease zu bekommen, auch wenn wie im Beispiel RHEL 8.5 bereits verfügbar ist, müssen Repositories mit verlängertem Support (z.B. Extended Update Support, EUS) verwendet werden. Andernfalls bekommt man keine Paketupdates.

Weiterführende Informationen zum Thema Extended Update Support bietet der Link unter [3].

Der folgende Code-Block zeigt, wie man Updates für ein RHEL-8-System auf das Release 8.4 beschränkt:

# subscription-manager release --set=8.4
# rm -rf /var/cache/dnf

Das Kommando in der letzten Zeile, geht auf den Wissensartikel [1] zurück, welcher darauf hinweist, dass nur so der Paket-Cache sicher geleert wird. Dies ist notwendig, da der Paketmanager andernfalls fälschlicherweise Paketversionen eines höheren Release aus dem lokalen Cache installieren könnte, was zu Abhängigkeitsproblemen führt.

Mit folgendem Befehl lässt sich die Beschränkung wieder entfernen:

# subscription-manager release --unset
   Release preference has been unset

Das war auch schon alles.

Quellen und weiterführende Links

1. How to tie a system to a specific update of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/238533 (Login erforderlich)
2. How to limit updates a [sic] specific version of Red Hat Enterprise Linux? — https://access.redhat.com/solutions/2761031 (Login erforderlich)
3. Red Hat Enterprise Linux (RHEL) Extended Update Support (EUS) Overview — https://access.redhat.com/articles/rhel-eus (Login erforderlich)

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

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

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

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/

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

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.

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.

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/

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/