Die Zukunft von Flatpak

• Flatpak ist derzeit bei Entwicklern und Nutzern beliebt, doch beim Projekt selbst tritt das Problem einer stagnierenden Entwicklung in den Vordergrund
• Durch den Weggang zentraler Entwickler und Engpässe verzögern sich die Umsetzung neuer Funktionen und Code-Reviews
• Verschiedene Erweiterungen wie OCI-Image-Unterstützung, feinere Berechtigungen und Zugriffskontrolle für Audio wurden vorgeschlagen, kommen in der Praxis jedoch nur langsam voran
• Für die langfristige Weiterentwicklung des Projekts werden die Einführung von Container-Technologiestandards (OCI) und eine Neuimplementierung auf Basis von Rust diskutiert
• Die Lösung zentraler Probleme wie Portal-Verbesserungen, Treiberunterstützung und Netzwerk-Sandboxing ist entscheidend für das weitere Wachstum von Flatpak

---

Überblick und aktueller Stand des Flatpak-Projekts

• Flatpak begann 2007 als ähnliches Projekt, erschien 2015 erstmals als XDG-App und wurde 2016 in Flatpak umbenannt
• Es bietet Kommandozeilen-Tools, Build-Tools und Runtime-Komponenten und nutzt cgroups, namespaces, bind mount, seccomp, Bubblewrap und mehr zur Anwendungsisolation (Sandboxing)
• OSTree ist der Standardmechanismus für die Auslieferung; in jüngerer Zeit wurde auch OCI-Image-Unterstützung integriert, die unter anderem in Fedora genutzt wird
• Das Wachstum des Flathub-App-Stores und die Übernahme durch Distributionen gelten als Erfolg, intern erlebt das Projekt jedoch eine Verlangsamung der aktiven Entwicklung

Entwicklungsstillstand und Hauptursachen

• Wartung und Security-Patches finden weiterhin statt, doch die Entwicklung größerer neuer Funktionen und Code-Reviews steckt seit längerer Zeit fest
• Durch den Weggang wichtiger Entwickler (u. a. Larsson) fehlen Reviewer, was die Aufnahme neuer Mitwirkender und größere Änderungen erschwert
• Auch Funktionen wie die von Red Hat mitentwickelte Flatpak-Preinstall-Funktion litten unter verzögerten Reviews und dem Wegfall zuständiger Personen, sodass sich die Integration wiederholt über Monate hinzog

OSTree und OCI-Image-Unterstützung

• OSTree wurde in Flatpak erfolgreich eingesetzt, erfährt aber wegen nicht standardisierter bzw. eingeschränkter Tools kaum noch aktive Weiterentwicklung über die Wartung hinaus
• Für OCI existiert ein breites Tool-Ökosystem für Container-Images, wodurch sich das Flatpak-Team bei einer Einführung geringerer Wartungsaufwand und weniger doppelte Arbeit erhofft
• Unterstützung für effiziente Kompressionsformate wie zstd:chunked wurde ebenfalls in neuen PRs vorgeschlagen, bleibt aber verzögert und unintegriert

Berechtigungsverwaltung und feinere Sandbox-Aufteilung

• Flatpak konzentriert sich auf die Einschränkung des Systemzugriffs durch Sandboxing; in aktuellen Versionen werden auch feinere Berechtigungen unterstützt (z. B. --device=input)
• Da Linux-Distributionen unterschiedliche Flatpak-Versionen ausliefern, entstehen Probleme, weil neue Berechtigungsfunktionen nicht breit ausgerollt werden und Versionskompatibilität berücksichtigt werden muss
• Bei Audio-Berechtigungen ist durch die Begrenzungen von PulseAudio eine Trennung von Wiedergabe und Aufnahme schwierig; Verbesserungen durch PipeWire werden daher als notwendig angesehen
• Die Unterstützung für verschachteltes Sandboxing ist unzureichend, sodass etwa Webbrowser intern keine zusätzlichen Sandboxes nutzen können

D-Bus- und Netzwerk-Sandboxing

• Flatpak greift nicht direkt auf D-Bus zu, sondern nutzt xdg-dbus-proxy für gefilterte Kommunikation
• Wick möchte die Filterrichtlinien in den D-Bus-Broker verlagern, um Richtlinien dynamisch anzuwenden und eine cgroup-basierte Zugriffskontrolle umzusetzen
• Wegen einer unvollständigen Umsetzung von Netzwerk-Namespaces besteht bei exponierten localhost-Ports die Möglichkeit unbeabsichtigter Kommunikation zwischen Flatpak-Apps (reales Beispiel: AusweisApp)
• NVIDIA-Treiber werden für jede Runtime separat bereitgestellt, was übermäßigen Netzwerkverkehr und schwierige Updates verursacht. Nach dem Vorbild von Valve werden Host-Sharing und statische Kompilierung als Optionen geprüft

Nutzung und Verbesserungsbedarf bei Portalen

• Portale sind D-Bus-basierte APIs für den Zugriff auf externe Ressourcen und übernehmen verschiedene Aufgaben wie Dateien, Drucken und URLs
• Portale wie Documents funktionieren auf Dateiebene gut, doch bei produktiven Apps wie GIMP oder Blender stößt das zu stark granulare Berechtigungsmodell an seine Grenzen
• Zusammen mit Vorschlägen für neue APIs wie Passwort-Autovervollständigung, FIDO-Schlüssel und Sprachsynthese werden auch eine leichtere Entwicklung und eine Neuimplementierung in Rust diskutiert

Die Zukunft von Flatpak (Flatpak-next)

• Ausgehend von der Annahme, dass Flatpak künftig nicht mehr weiterentwickelt werden könnte, wird langfristig ein großer Wechsel in das OCI-Ökosystem diskutiert (für Images, Registries, Tools, Richtlinien und mehr)
• Eine Neuimplementierung auf Basis von Rust und die Einordnung in das Container-Ökosystem versprechen Vorteile bei Verwaltungsaufwand, Wartung und Erweiterbarkeit

Zusammenfassung der Fragen und Antworten

• Auf die Frage, wie bestehende Flatpak-Apps bei einem Wechsel zu OCI behandelt würden, wurde geantwortet, dass dies dank Build-Automatisierung bei Flathub kein großes Problem sei
• Beim Mangel an Metadaten in OCI-Registries hieß es, dass Standards für Nicht-Image-Daten entstehen, für die praktische Nutzung aber noch Entwicklung und Integration nötig seien
• Zur geplanten direkten Unterstützung von PipeWire wurde erklärt, dass technische Diskussionen laufen und die Richtung auf eine policy-basierte Integration mit PipeWire weise

Fazit

• Flatpak hat sich als Standardplattform für Verteilung und Sandboxing etabliert, steht aber vor mehreren Baustellen wie stockenden Reviews und Neuentwicklungen, Problemen bei Berechtigungen, Netzwerk und Treibern sowie einem möglichen Wechsel künftiger Standards
• OCI-basierte Container-Technologien und der Einsatz von Rust könnten zu einem neuen Entwicklungsmotor für Flatpak werden
• Die wichtigsten Punkte lassen sich als Gewinnung von Reviewern, Standardisierung, Ausbau des Ökosystems und Verbesserung der User Experience zusammenfassen

[ndrgrd]

Ich finde es besser, den Zugriff nicht komplett zu blockieren, sondern klar anzuzeigen, auf welches Verzeichnis zugegriffen wird.

Android ist in dieser Hinsicht ganz okay, aber dort sind die Berechtigungen zu grob zusammengefasst, sodass man auch Berechtigungen auf einem Niveau erlauben muss, die man eigentlich nicht braucht ...

[GN⁺]

Hacker-News-Kommentare

• Aus Wicks Vortrag wurde hervorgehoben, dass das Flatpak-Projekt nach außen zwar gut zu laufen scheint, tatsächlich aber kaum aktiv weiterentwickelt wird. Sicherheitsupdates und einfache Wartung laufen weiter, neue Funktionen kommen jedoch fast nicht hinzu. Dass viele Feature-Vorschläge als Merge Requests eingereicht werden, aber niemand sie prüft und dadurch Stillstand entsteht, halte ich für problematisch. Besonders nachdem in RHEL 10 die Bereitstellung von Desktop-Paketen eingestellt und stattdessen die Installation von Paketen über Flathub empfohlen wurde, ist die Rolle von Red Hat noch wichtiger geworden. Wenn Red Hat Flatpak wirklich zu einem vollwertigen Ersatz machen will, sollte es mehr Ressourcen investieren. Ich stimme auch Wicks Hinweis zu, dass je nach Flatpak-Version die Unterstützung neuer Berechtigungen unterschiedlich ausfällt und daher Backwards Compatibility nötig ist. Beim Verteilen eigener Spiele auf Flathub habe ich selbst Probleme mit Audio- und Controller-Berechtigungen, fehlender Unterstützung für --device=input und der Unmöglichkeit erlebt, Berechtigungen feiner zu steuern, etwa nur Lautsprecher freizugeben, aber das Mikrofon zu blockieren.
  • Es wird auch erwähnt, dass Red Hat Firefox und Thunderbird zunächst in RHEL 10 ausschließlich als Flatpak ausliefern wollte, nach dem GA-Release dann aber doch auch RPM-Pakete bereitgestellt hat. Dahinter standen mehrere Gründe zugleich, darunter fehlende Unterstützung für Native Messaging, keine zentrale Richtlinienverteilung und Probleme bei der Desktop-Integration.
• Es wurde eine Erfahrung geteilt, bei der man zu Beginn von Flatpak den ursprünglichen Entwickler direkt getroffen und mit ihm über die Designphilosophie diskutiert hatte. Man habe versucht zu erklären, dass es problematisch sei, dass Berechtigungen an den Paketnamen gebunden sind und nicht pro Instanz getrennt werden. Das bedeutet: Dieselbe Flatpak-App lässt sich nicht in mehreren Instanzen mit unterschiedlichen Berechtigungen starten, etwa so, dass nur ein bestimmtes Unterverzeichnis unter Documents erlaubt ist. Diese Struktur sei bei Microsoft, Apple App Store und macOS ähnlich, und man halte die gesamte Welt hier für falsch designt. Wenn etwa in einem LibreOffice-Dokument eine RCE (Remote Code Execution) ausgelöst wird, sollte der Zugriff auf andere Dokumente blockiert werden. Die Argumentation lautet, dass die Flatpak-Sandbox Sicherheit bieten sollte, auch wenn der Anbieter selbst Sicherheit nicht ernst genug nimmt.
  • Dem steht eine kritische Sicht auf die steigende Komplexität aus Sicherheitsgründen gegenüber. Ein PC gehöre seinem Besitzer, deshalb seien instanzbezogene Berechtigungen, Sandboxen und Einschränkungen beim Dateiaustausch unnötig, und das traditionelle Konzept „alles ist eine Datei“ solle erhalten bleiben. Als Beispiel wird Unzufriedenheit mit Sandbox-Umgebungen genannt, in denen Thunderbird und Firefox nicht auf das Verzeichnis /tmp zugreifen können, wodurch das Speichern von Anhängen und das Öffnen in anderen Apps extrem unpraktisch wird. Der Eigentümer des Computers solle der Nutzer sein, nicht der Entwickler. Solch überzogene Sicherheit führe aus dieser Sicht zu Produktivitätsverlust und wird mit der Useless Machine verglichen.
  • Es wird die Möglichkeit angesprochen, dass auch die Flatpak-Entwickler dieses Problem verstanden haben. Hätte Flatpak technisch von Anfang an ein perfektes Modell gewählt, wäre die Einstiegshürde für App-Entwickler, besonders für Multiplattform-Entwickler, womöglich zu hoch gewesen, sodass sich Flatpak selbst nicht hätte verbreiten können.
  • Ein instanzbezogenes Berechtigungsmodell wird als sehr attraktiv beschrieben, zugleich wird aber ein hybrider Ansatz als praktikabel vorgeschlagen, bei dem für Konfigurationen wie git config, Schriftartenordner usw. optional alle Instanzen dieselben Zugriffsrechte erhalten.
  • Als wünschenswert wird gesehen, das Betriebssystem insgesamt neu zu gestalten, sodass jede laufende Instanz eigene Capabilities, Disk-Quotas, Logging, Proxys und eine feinere Trennung von Berechtigungen erhalten kann. Das sei kein reines Flatpak-Problem.
  • Für Power-User und sicherheitssensible Nutzer, die wie bei QubesOS eine strikte Trennung per Hypervisor-basierter Sandbox brauchen, sei eine Trennung pro Instanz sinnvoll. Die meisten Isolationsaufgaben würden jedoch intuitiver innerhalb der App selbst stattfinden. Wie beim Sandboxing von Webbrowsern wäre auch für Flatpak Support für verschachtelte Sandboxes ideal, derzeit wird das aber nicht unterstützt. Dazu kommen recht komplexe Probleme wie die Verknüpfung von Code-Signing und Sandbox sowie UID-Namespaces.
• Als langjähriger begeisterter Flatpak-Nutzer wurde die Erfahrung geteilt, dass Flatpak einst innovativ war und aktuelle Apps auf allen Linux-Distributionen leicht nutzbar machte, sich in den letzten Jahren aber kaum verändert hat, wodurch das Interesse allmählich nachließ. Heute deckt AUR das meiste ab, und der Stillstand bei Flatpak ist bedauerlich.
  • Als Nutzer habe man mit Flatpak abgesehen von der Einfachheit keine wirklich guten Erfahrungen gemacht. Genannt werden zahlreiche Integrationsprobleme bei Themes, Cursor, File Picker, Berechtigungen und Drag-and-Drop sowie der Bedarf an zusätzlichen Tools zur Nutzung bestimmter Funktionen. Solange die UX schwach ist, seien Sicherheitsvorteile wie Sandboxing bedeutungslos. Gäbe es unter Linux keine Probleme mit der Portabilität von Binärdateien, wäre Flatpak aus dieser Sicht unnötig.
  • Die Kombination Fedora+GNOME+Flatpak habe sich einmal sehr innovativ angefühlt, inzwischen sei man aber wieder zu Arch zurückgekehrt. Die Arch-Repositories seien viel umfangreicher geworden, und AUR werde kaum noch benötigt.
  • Jemand mit Erfahrung in der Pflege vieler Pakete fragt nach Erfahrungen mit makedeb. Da makedeb auf PKGBUILD basiert, sei es sehr portabel, und man wundere sich, warum es nicht bekannter ist.
• Man stimmt Drew DeVaults Argument „Distributionen sollten das App-Packaging übernehmen“ zwar nicht zu 100 % zu, verweist aber auf seinen langjährigen Diskussionsbeitrag und den Referenzlink. Dahinter steht die Sicht, dass das Community-Modell, bei dem Distributionen im Namen der Nutzer Pakete verwalten, das richtige ist. Modelle wie Flatpak/Snap/AppImage, bei denen außerhalb der Distribution paketiert wird, seien grundsätzlich nicht gut.
  • Dagegen wird eingewandt, dass Entwickler, die eine App direkt erstellen, am besten für das Paketmanagement geeignet seien. Gerade bei proprietärer Software liegen die Rechte zur Verteilung und Paketierung rechtlich exklusiv dort. Selbst bei Open Source führe ein Eingreifen von Personen außerhalb des Kernteams beim Paketieren aus dieser Sicht nur zu unnötigen Bugs, verzögerten Releases und neuen Problemen. Gewünscht werden schnelle und aktuelle Updates sowie unveränderte Originalsoftware ohne Manipulation im Packaging. Das Problem sei, dass Flatpak zu viele Rollen zugleich übernehmen wolle. Auch das App-Store-Modell selbst wird skeptisch gesehen: Unter Windows und macOS könne Software auch ohne App Store frei als Binärdatei verteilt werden, während minimale Sicherheit auf OS-Ebene etwa durch Code-Signing bereitgestellt werde. Von Dritten dominierte Paketierungssysteme seien unnötig.
  • App-Entwickler sollten direkt verteilen können; als Beispiel wird die einfache Installations-Erfahrung unter Windows genannt. Maintainer hätten oft nicht die Größe, um alle Distributionen zu unterstützen, und das sei ein Hindernis für den Fortschritt des Linux-Desktops.
  • Es wird darauf hingewiesen, dass der Aufwand, jede Distribution einzeln zu paketieren, dem Ganzen am Ende sogar den Sinn nimmt.
  • Die Vorstellung, dass Distributionen sämtliche Software der Welt paketieren, wird als unrealistisch bezeichnet.
  • Aus der Sicht, dass Distributionen beim App-Packaging schlechte Arbeit leisten, freut man sich über die zunehmende Verbreitung von Flatpak. Entwickler sollten ihre Apps ohne Mittelsmänner leicht ausliefern können.
• Es wird der Kritik zugestimmt, dass Flatpak weiterhin auf PulseAudio setzt und deshalb bei der Einführung von PipeWire hinterherhinkt. PulseAudio bündelt Lautsprecher- und Mikrofon-Berechtigungen und erlaubt keine Trennung. Wenn eine App also das Recht zur Audioausgabe erhält, kann sie automatisch auch auf das Mikrofon zugreifen, was als erhebliches Sicherheitsloch gesehen wird.
  • Man sehe oft Linux-Nutzer, die Designfehler oder mangelnde Freiheit unter Windows und macOS verspotten, doch solche grundlegenden Designprobleme müssten auch hier anerkannt werden. Das Linux-Ökosystem neige dazu, Probleme liegenzulassen, ohne Verantwortlichkeiten klar zu benennen.
• VSCode/Codium wurde für Python-Debugging als Flatpak installiert, doch die Einrichtung des Debuggers habe wegen Berechtigungs- und Konfigurationsproblemen sehr lange gedauert. Nach dem Wechsel zur Snap-Version seien alle Probleme verschwunden.
  • Flatpak sei für große Apps wie Chrome oder Chromium und allgemein Desktop-Anwendungen geeignet, aber ungeeignet für Systemwerkzeuge.
  • Die Flatpak-Version von Emacs habe nur Ineffizienz und Frust gebracht.
• Beim Wechsel auf eine immutable distro auf Flatpak-Basis kann es gut funktionieren, wenn alles passt, erfüllt die Erwartungen aber oft nicht, weil überraschend viele Dinge nicht laufen. Genannt werden Probleme wie das Starten externer Tools für Godot, zahlreiche Permission-Tweaks, die Interaktion zwischen Flatpaks untereinander wie etwa Firefox und KeepassDX, Abstürze von Godot- und Krita-Flatpaks sowie die Mischung mit nicht-Flatpak-Umgebungen wie AppImage oder .rpm. Man wünsche sich deutlich mehr Innovation bei Flatpak.
• Mit Flatpak lassen sich Apps wie Tailscale, die virtuelle Netzwerkschnittstellen anlegen, strukturell nicht paketieren. macOS bietet dagegen APIs, um Netzwerkberechtigungen feiner zu steuern, sodass auch Tailscale im Mac App Store als Sandbox-App verteilt werden kann.
  • Dank dieser APIs ist eine Sandbox-App-Auslieferung von Tailscale für macOS möglich. Auf „atomaren“ Linux-Distributionen wie Silverblue oder Bluefin, die stark auf Flatpak setzen, ist der Einsatz solcher Software dagegen schwierig.
  • Für große Desktop-Apps wie OBS Studio sei Flatpak sinnvoll, aber für Tailscale, das eher wie ein Systemdienst arbeitet, sei ein distributionsinternes Paket passender. Unter Arch Linux gibt es dafür ein offizielles Paket.
  • In Flatpak seien Umgehungslösungen wie flatpak-spawn oder polkit-exec möglich, damit gebe man den Schutz der Sandbox jedoch fast vollständig auf.
  • Der Versuch, auf Linux ganz oben gleichzeitig ein feingranulares Berechtigungssystem und ein Packaging-System zu lösen, sei übermäßig komplex. Darin könnten auch die Stagnation von Flatpak oder die Erschöpfung der Entwickler begründet liegen. Da modernes Linux kein grundlegendes Berechtigungssystem habe, seien Softwareverteilung, Packaging und Update-Mechanismen zunächst die dringendere Realität als perfekte Permission-Modelle.
  • Dinge wie Tailscale gehörten eher in sysext als in Flatpak.
• Im Zusammenhang mit Flatpak als Distributionsvorschlag wurde berichtet, dass man bei der Entwicklung der Java-basierten App KmCaster zur Portierung auf Flatpak aufgefordert wurde, dabei aber nur zusätzliche Last gespürt habe: zwei Installationswege, Verwaltung von Download-Statistiken, Vertrauen in Third-Party-Repositories, ein weiterer neuer Paketmanager und doppelte Repositories. Praktische Vorteile habe es kaum gegeben.
  • Trotzdem werden positive Seiten von Flatpak genannt: die bequeme Nutzung auf immutable distros, kein Bedarf mehr an eigenem Java-Versionsmanagement, Sichtbarkeit in der Flathub-Suche und automatische Updates.
• Obwohl man weder Open-Source-Maintainer noch Entwickler sei, könne man nicht verstehen, warum so viele Linux-Distributionen alle mit denselben Paketproblemen zu kämpfen haben und ihre Kräfte nicht bündeln, um Flatpak zu verbessern und zu verbreiten.
  • Da jede Distribution ihre eigene Art der Distribution hat, sei eine Vereinheitlichung schwierig, und gerade die Vielfalt an Wahlmöglichkeiten sei eine Stärke des Open-Source-Ökosystems. Persönlich bevorzuge man traditionelle System-Paketmanager.
  • Nach derselben Logik dürfte es dann auch nur GNOME geben; Vielfalt in Community und Entscheidungsfindung sei wichtig.
  • Flatpak sei für einen selbst völlig nutzlos, und man wolle nicht dazu gedrängt werden, zu Software beizutragen, die man nicht benutzt.