Release des selbständigen Paket-Systems Flatpak 1.14.0

Ein neuer stabiler Branch des Flatpak-Tools 1.14 wurde veröffentlicht, das ein System zur Erstellung selbständiger Pakete bietet, die nicht an bestimmte Linux-Distributionen gebunden sind und in einem speziellen Container ausgeführt werden, der die Anwendung vom Rest des Systems isoliert. Die Ausführung von Flatpak-Paketen wird für Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux und Ubuntu unterstützt. Flatpak-Pakete sind im Fedora-Repository enthalten und werden von der integrierten Anwendungsverwaltungssoftware GNOME unterstützt.

Wichtige Neuerungen im Branch Flatpak 1.14:

• Es wurde ein Verzeichnis für Dateien im Zustand (.local/state) erstellt, und die Umgebungsvariable XDG_STATE_HOME wurde auf dieses Verzeichnis gesetzt.
• Bedingte Überprüfungen in der Form „have-kernel-module-Name“ wurden hinzugefügt, um die Verfügbarkeit von Kernelmodulen zu bestimmen (ein universeller Ersatz für die zuvor angebotene Überprüfung have-intel-gpu; stattdessen kann jetzt der Ausdruck „have-kernel-module-i915“ verwendet werden).
• Der Befehl „flatpak document-unexport —doc-id=…“ wurde implementiert.
• Die Exportierung von Appstream-Metadaten zur Verwendung in der Hauptumgebung wurde sichergestellt.
• Auto-Vervollständigungsregeln für Flatpak-Befehle wurden für die Shell Fish hinzugefügt.
• Der Netzwerkzugang zu X11- und PulseAudio-Diensten wurde erlaubt (bei Hinzufügung entsprechender Einstellungen).
• Der Hauptbranch im Git-Repository wurde von „master“ in „main“ umbenannt, da das Wort „master“ in letzter Zeit als unpolitisch korrekt angesehen wird.
• Die Überschreibung von Startskripten im Fall einer Umbenennung der Anwendung wurde sichergestellt.
• Den install-Befehl wurden die Optionen „—include-sdk“ und „—include-debug“ zum Installieren von SDK und Debuginfo-Dateien hinzugefügt.
• Die Dateien flatpakref und flatpakrepo unterstützen jetzt den Parameter „DeploySideloadCollectionID“, bei dessen Installation die Identifikation der Sammlung beim Hinzufügen des Remote-Repositorys festgelegt wird, und nicht erst nach dem Herunterladen der Metadaten.
• Das Erstellen von verschachtelten Sandbox-Umgebungen für Handler in Sitzungen mit separaten MPRIS-Namen (Media Player Remote Interfacing Specification) wurde ermöglicht.
• In den Kommandozeilen-Utilities wird die Ausgabe von Informationen zur Verwendung veralteter Runtime-Erweiterungen sichergestellt.
• Im Uninstall-Befehl wurde eine Bestätigungsanfrage vor der Entfernung von Runtime oder Runtime-Erweiterungen, die noch verwendet werden, implementiert.
• Den Befehlen wie „flatpak run“ wurde die Unterstützung der Option „—socket=gpg-agent“ hinzugefügt.
• In libostree wurde eine Sicherheitsanfälligkeit behoben, die es einem Benutzer möglicherweise ermöglicht, beliebige Dateien im System durch Manipulation des flatpak-system-helper Handlers (Versenden einer Anfrage zur Löschung mit einem speziell formatierten Branch-Namen) zu löschen. Das Problem tritt nur in älteren Versionen von Flatpak und libostree auf, die vor 2018 veröffentlicht wurden (< 0.10.2), und betrifft nicht die aktuellen Versionen.

Wir erinnern daran, dass Flatpak-Anwendungsentwicklern die Möglichkeit bietet, die Verbreitung ihrer Programme zu vereinfachen, die nicht in den Standard-Repositories der Distributionen verfügbar sind, indem sie einen universellen Container vorbereiten, ohne separate Builds für jede Distribution erstellen zu müssen. Benutzern, die auf Sicherheit bedacht sind, ermöglicht Flatpak, problematische Anwendungen in einem Container auszuführen und dabei nur auf Netzwerkfunktionen sowie auf benutzerspezifische Dateien zuzugreifen, die mit der Anwendung in Verbindung stehen. Benutzern, die an Neuigkeiten interessiert sind, erlaubt Flatpak, die neuesten Test- und stabilen Versionen von Anwendungen zu installieren, ohne Änderungen am System vorzunehmen. Beispielsweise werden Flatpak-Pakete für LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio usw. bereitgestellt.

Um die Paketgröße zu reduzieren, enthält es nur spezifische Abhängigkeiten für die Anwendung, während grundlegende system- und grafikbibliotheken (GTK, Qt, GNOME- und KDE-Bibliotheken usw.) als Plug-in-Standard-Runtime-Umgebungen bereitgestellt werden. Der wesentliche Unterschied zwischen Flatpak und Snap besteht darin, dass Snap die Komponenten der Hauptsystemumgebung und eine Isolation auf der Basis von gefilterten Systemaufrufen verwendet, während Flatpak einen vom System getrennten Container erstellt und große Runtime-Sets verwendet, wobei nicht Pakete, sondern Standard-Systemumgebungen (zum Beispiel alle Bibliotheken, die für die Ausführung von GNOME- oder KDE-Programmen erforderlich sind) als Abhängigkeiten bereitgestellt werden.

Neben der typischen Systemumgebung (runtime), die über ein spezielles Repository installiert wird, werden zusätzliche Abhängigkeiten (bundle) bereitgestellt, die für den Betrieb der Anwendung erforderlich sind. Zusammen bilden runtime und bundle die Inhalte des Containers, wobei runtime separat installiert wird und gleichzeitig mit mehreren Containern verbunden ist, was eine Duplizierung gemeinsamer Systemdateien für die Container vermeidet. In einem System können mehrere unterschiedliche runtimes (GNOME, KDE) oder mehrere Versionen einer runtime (GNOME 3.40, GNOME 3.42) installiert werden. Der Container mit der Anwendung als Abhängigkeit verwendet die Bindung nur an eine bestimmte runtime, ohne Berücksichtigung der einzelnen Pakete, aus denen die runtime besteht. Alle fehlenden Elemente werden direkt mit der Anwendung verpackt. Bei der Erstellung des Containers wird der Inhalt der runtime als Partition /usr gemountet, während das bundle im Verzeichnis /app gemountet wird.

Die Inhalte der runtime und der Anwendungscontainer werden mit der OSTree-Technologie erstellt, bei der das Abbild atomar aus einem git-ähnlichen Repository aktualisiert wird, das es ermöglicht, Methoden der Versionskontrolle auf die Komponenten des Distributionspakets anzuwenden (zum Beispiel kann das System schnell in einen vorherigen Zustand zurückgesetzt werden). RPM-Pakete werden über eine spezielle Schicht rpm-ostree in das OSTree-Repository übertragen. Eine separate Installation und Aktualisierung von Paketen innerhalb der Arbeitsumgebung wird nicht unterstützt, das System wird nicht auf der Ebene einzelner Komponenten, sondern als Ganzes aktualisiert, indem es atomar seinen Zustand ändert. Es stehen Mittel zur Verfügung, um inkrementelle Aktualisierungen anzuwenden, die die Notwendigkeit einer vollständigen Ersetzung des Abbilds bei jeder Aktualisierung beseitigen.

Die gebildete isolierte Umgebung ist vollständig unabhängig von der verwendeten Distribution und hat bei ordnungsgemäßer Paketkonfiguration keinen Zugang zu den Dateien und Prozessen des Benutzers oder des Hauptsystems, kann nicht direkt auf die Hardware zugreifen, mit Ausnahme der Ausgabe über DRI, sowie Zugriffe auf die Netzwerksubsystem. Die Ausgabe der Grafik und die Eingabeverwaltung erfolgen über das Protokoll Wayland oder durch das Durchreichen von X11-Sockets. Die Interaktion mit der Außenwelt basiert auf dem DBus-Nachrichtenaustauschsystem und einer speziellen API namens Portals.

Für die Isolierung wird die Schicht Bubblewrap sowie traditionelle Technologien zur Container-Virtualisierung unter Linux verwendet, die auf cgroups, Namespaces, Seccomp und SELinux basieren. Zur Audioausgabe wird PulseAudio eingesetzt. Dabei kann die Isolierung deaktiviert werden, was Entwickler vieler populärer Pakete nutzen, um vollständigen Zugriff auf das Dateisystem und alle Geräte im System zu erhalten. So werden Pakete wie GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity und VLC mit einem eingeschränkten Isolationsmodus geliefert, der vollen Zugriff auf das Home-Verzeichnis gewährt. Im Falle einer Kompromittierung der Pakete mit Zugriff auf das Home-Verzeichnis reicht es für einen Angreifer, der Beschreibung des Pakets das Label „sandboxed“ zum Trotz, die Datei ~/.bashrc zu ändern. Ein separates Thema ist die Kontrolle über Änderungen an den Paketen und das Vertrauen in die Paketbauer, die häufig nicht mit dem Hauptprojekt oder den Distributionen verbunden sind.

Quelle: opennet.ru