Es ist eine verzwickte Lage, in der sich das Gnome-Projekt befindet: Während der verbreitete Linux-Desktop technisch auf sicheren Beinen steht, sieht es finanziell weniger gut aus. In den vergangenen Jahren sind Spenden zurückgegangen, während die Kosten blieben. Trotz der angespannten finanziellen Lage stellte das Gnome-Projekt eine Hybrid-Konferenz auf die Beine. Beteiligte und Interessierte aus Übersee, Europa und weiteren Ländern trafen sich Ende Juli zur jährlichen Gnome-Konferenz GUADEC. Die fand auf Sparflamme in der Lombardei an der Universität in Brescia statt.

Die Vorträge präsentierten einerseits die Fortschritte der letzten Monate bei etwa beim Toolkit GTK, der Gnome-Shell und den für Flatpak wichtigen XDG-Desktop-Portals. Auch Themen wie Barrierefreiheit und Sicherheit sowie die Projektentwicklung, etwa um Maintainer-Burn-out zu verhindern, wurden verhandelt. Auf der während der GUADEC stattfindenden Jahreshauptversammlung der Gnome-Foundation zeigte sich, dass ein Konflikt aus dem vergangenen Jahr die Gnome-Mitglieder weiter beschäftigt.

Fortschritte bei der Barrierefreiheit

Red-Hat-Mitarbeiter Lukáš Tyrychtr präsentierte die jüngsten Fortschritte bei der Barrierefreiheit von Wayland und Gnome, insbesondere für Blinde. In der Vergangenheit gab es immer wieder Kritik in diesem Bereich. Zunächst erläuterte er den Anwesenden, wie ein Screenreader funktioniert und weshalb daraus spezielle Herausforderungen entstehen. Denn ein Screenreader beschränkt sich nicht auf Vorlesen von Text, sondern muss auch jegliche Keyboard-Events mitbekommen und manche sogar abfangen, sodass die weder beim Compositor, etwa „Mutter“ von der Gnome-Shell, noch bei der aktuell verwendeten Anwendung landen. Beispielsweise nutzen Blinde häufig eine Funktion, um den vorgelesenen Text abzubrechen.

Änderungen beim Accessibility-Dienst AT-SPI2 und die Einführung von GTK 4 mit eigenem Accessibility-Bus hatten dazu geführt, dass GTK-4-Apps unter Wayland nicht mit dem Screenreader Orca zusammenarbeiteten. Dieses Problem blieb mehrere Jahre ungelöst. Gemeinsam mit weiteren Red-Hat-Mitarbeitern entwarf Tyrychtr, der selbst blind ist, einen neuen Ansatz, bei dem Tasten-Events nicht mehr in der App abgefangen werden, sondern schon im Compositor. Da vorher viel Verkehr auf dem Accessibility-Bus unterwegs war, wird jetzt nur noch ein Event gesendet, wenn ein Screenreader auch lauscht. Außerdem wird der DBus-Name gegen eine Allowlist geprüft, damit nicht ein beliebiger Prozess als Keylogger fungieren kann. Die Änderungen sind in AT-SPI2 core ab Version 2.56 sowie im Screenreader Orca 48, Gnome-Shell 48 und KDEs Fenstermanager Kwin 6.4 umgesetzt.

Unabhängig davon wurden die visuellen Warnungen in der Gnome-Shell angepasst, damit diese konform mit dem European Accessibility Act (EAA) sind. Zudem sind nun auf dem Anmeldebildschirm die Barrierefreiheitsoptionen prominenter platziert.

Aus Red Hats Accessibility Team gab es noch weitere Vorträge, etwa einen Barrierefreiheit-Workshop für App- und Shell-Entwickler. Da Blinde fast alles mit der Tastatur erledigen, appellierte Lukáš Tyrychtr an die Anwesenden, die Tastatur-User-Experience dürfe nicht schlechter werden. In einer Diskussionsrunde bezeichnete Gnome-Entwickler Emmanuelle Bassi Accessibility als Zwilling von Usability. Barrierefreiheit sei wichtig, damit auch wirklich alle Zugang zum Computer haben.

Farbenfrohe Gnome-Shell

Nicht nur die Barrierefreiheit hat sich in der Gnome-Shell seit Version 48 verbessert, sondern auch die Unterstützung für HDR hat Einzug erhalten. Nach jahrelanger Überarbeitung des Quellcodes vom Compositor Mutter und weiteren Komponenten lässt sich HDR jetzt systemweit nutzen. Läuft Gnome im Wayland-Modus und ist ein HDR-fähiger Bildschirm angeschlossen, erscheint in den Einstellungen ein entsprechender Schalter. Die Arbeiten sind damit nicht abgeschlossen. Auf der Agenda bleiben Tone-Mapping (HDR-Inhalte auf den vom Bildschirm unterstützten Bereich anpassen), Unterstützung für ICC-Profile, Farbmanagement auch ohne HDR, den Nachtmodus reparieren und die Darstellung von HDR-Inhalten im SDR-Modus.

Das Gnome-Shell-Team hat zudem zahlreiche intern genutzte Wayland-Protokolle allgemein verfügbar gemacht (Upstreaming). Das betrifft Farbmanagement, Farb-Konversionen, besseres Timing bei der Aktualisierung von Bildschirminhalten, etwa um Sprünge und Ruckler zu vermeiden, sowie einen Workaround, um Memory Leaks in Mesa zu umschiffen. Aktuell laufen letzte Arbeiten an einem Session-Management-Protokoll, um Programme und deren Fenster nach einer Neuanmeldung wiederherzustellen. Der aktuelle Entwurf des vielfach gewünschten Features enthält noch zu viele Bugs. Das ist auch aufgrund der eingeschränkten Rechte von Wayland-Clients nicht einfach umzusetzen; Anwendungen haben keinen Zugriff auf die gesamte Bildschirmfläche. Der Compositor hingegen muss beim Start einer Anwendung eventuell lange warten, ob sie selbst die alten Fenster bereitstellt, etwa weil es dauert, ein großes Projekt zu öffnen, oder weil der Nutzer genehmigen muss, dass die vorherige Session wiederhergestellt wird.

Durch die weitgehende Entfernung von X11-Code aus der Gnome-Shell fällt auch deren Nested-Option weg, mit der eine Session in einem Fenster geöffnet werden konnte. Das war vorwiegend für Shell-Entwickler zum Testen interessant, eine Aufgabe, die jetzt vom Development Kit übernommen wird, einer eigenständigen GTK-4-Anwendung, welche als separater Prozess läuft. Die kleine Zielgruppe der Shell-Entwickler dürfte freuen, dass es nun einfacher ist, Entwicklungen zu testen. Da das Development Kit die gleiche API wie der Remote-Desktop verwendet, dürfte letzterer davon profitieren, dass jetzt mehr Gnome-Hacker diese API nutzen.

Mehr Sicherheit

Auch wenn es gern behauptet wird, sind Linux-Systeme per se nicht sicherer als andere Betriebssysteme. Allerdings macht die geringe Verbreitung auf Desktop-Systemen Linux für Anwender-Schadsoftware unattraktiv. Darauf wies auch die spanische Sicherheitsforscherin und Freie-Software-Aktivistin Paule de la Hoz hin. Grundsätzlich lauern unter Linux fast die gleichen Gefahren wie anderswo, etwa verdeckte Krypto-Miner, Ransomware und Phishing. Toolkits für Schadsoftware böten mittlerweile auch Payloads für Linux-Systeme an. Gegenüber c’t gab de la Hoz an, dass noch vor allem Server und IoT-Geräte Ziel der Angriffe seien. Sie warnte aber davor, das Risiko von Software aus fragwürdigen Quellen zu unterschätzen oder blindlings Befehle aus dem Internet per Copy & Paste auf dem eigenen System auszuführen.

Der Gnome-Entwickler Michael Catanzaro rief in seinem Vortrag dazu auf, nicht weiter die Sandbox von Flatpak zu unterlaufen. Die sei essentiell, da es mit unsicheren Programmiersprachen wie C nie möglich sei, sicheren Code zu schreiben. Rust sei zwar vom Design her sicherer, aber hier lauern Risiken in den Abhängigkeiten (Supply Chain Security). „Unsere Rust-Anwendungen haben viel zu viele Abhängigkeiten“, warnte Catanzaro mit Verweis auf mehrere Hundert Abhängigkeiten einzelner Apps zu Rusts Cargo-Repository.

Er lobte hingegen die Flatpak-Sandbox, da diese eine abgeschottete Umgebung bereitstelle. Dies entbinde zwar nicht davon, Abhängigkeiten oder Code zu aktualisieren und sei auch nicht absolut sicher. Doch um aus der Sandbox heraus Schaden anzurichten, bräuchte ein Angreifer mindestens zwei Exploits, einen um den Programmcode der App auszutricksen und einen weiteren, um aus der Sandbox auszubrechen. In der Praxis würden allerdings viele Anwendungen zu weitreichende Berechtigungen anfordern, etwa den Zugriff auf das gesamte Dateisystem, und somit die Sandbox nichtig machen.

Die Schuld sieht Catanzaro nicht allein bei den App-Entwicklern, sondern prangerte auch fehlende oder unzureichende XDG-Desktop-Portals an. Diese Portals sind eine Schnittstellensammlung, die Apps dynamisch Zugriff auf Ressourcen einräumt, wenn Nutzer der Freigabe zustimmen, etwa auf eine Webcam oder eine bestimmte Datei. Man müsse mehr bei der Entwicklung der Portale zusammenarbeiten und brauche einen Plan, wie man die größten ausstehenden Fragen löst. Außerdem fehle es an einer Strategie, wie man mit Anwendungen umgeht, die legitimerweise nicht in einer Sandbox laufen könnten.

Angesichts solcher Anforderungen ist es wenig verwunderlich, dass die Keynote von Mirko Brombin, Entwickler der innovativen Linux-Distribution Vanilla OS und des WINE-Tools Bottles, nicht auf besonders fruchtbaren Boden fiel. Brombin stellte cpak vor, ein neuer Weg für Linux, um Kommandozeilentools, Dienste und Anwendungen zu paketieren. Dabei baut cpak auf Standards der Open Container Initiative (OCI) auf, also den von Docker genutzten Container-Images. Diese werden mit einer cpak.json-Datei kombiniert, welche unter anderem die benötigten Rechte und Ressourcen definiert. Laut Brombin ist cpak primär für Embedded-Geräte entwickelt worden und positioniert sich zwischen Docker und Flatpak beziehungsweise Snap. Im Unterschied zu diesen benötige cpak keine Hintergrunddienste, sondern bestehe nur aus einer einzigen eigenständigen Binary (cpak), welche das jeweilige cpak-Bundle ausführe. Viele kritische Rückfragen aus dem Plenum bezogen sich auf Sicherheitsaspekte. Zwar sieht cpak eine Trennung zwischen cpak-Anwendungen und Host-System vor, aber mehrere Anwesende bemängelten, dass diese schon im Aufbau ungenügend sei oder man sie anderweitig unterlaufen könne.