Release des Systems für selbstständige Pakete Flatpak 1.18.0

Nach eineinhalb Jahren Entwicklung wurde die neue stabile Version des Flatpak-Toolkits 1.18 veröffentlicht, das ein System zur Erstellung eigenständiger Pakete bereitstellt, die nicht an spezifische Linux-Distributionen gebunden sind und in einem speziellen Container ausgeführt werden, der die Anwendung vom restlichen System isoliert. Die Ausführung von Flatpak-Paketen wird für Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux und Ubuntu unterstützt. Flatpak-Pakete sind im Fedora-Repository enthalten und werden von den standardmäßigen Anwendungsverwaltungstools GNOME und KDE unterstützt.

Wichtige Neuerungen in der Flatpak-Version 1.18:

• Die Unterstützung für bedingte Berechtigungen (conditional permission) wurde implementiert, mit denen bei der Anforderung von Berechtigungen bestimmte Funktionen im System oder zur Laufzeit überprüft werden können. Zum Beispiel kann anstelle von „—device=all“ bei Bedarf auf ein Eingabegerät die Berechtigung „—device-if=all:!has-input-device —device=input“ angefordert werden, die den Zugriff nur auf Eingabegeräte gewährt oder auf den Zugriff auf alle Geräte zurückfällt, wenn die selektive Zugangsgewährung zur Laufzeit nicht unterstützt wird. Ebenso kann der Zugang zu USB-Geräten („has-usb-device“ und „has-usb-portal“) oder gemeinsam genutzten Subsystemen angefordert werden.
• Zugriff auf das Gerät /dev/ntsync wurde gewährt, um auf
  das NTSYNC-Kernelmodul zuzugreifen, das eine Sammlung von Synchronisationsprimitive bereitstellt, die im Windows NT-Kernel verwendet werden, und die Leistung von Windows-Spielen, die mit Wine gestartet werden, erheblich steigern können.
• Für Intel Xe GPUs ist die Unterstützung der VA-API für die Hardwarebeschleunigung der Video-Dekodierung hinzugefügt worden.
• Die Möglichkeit, auf das Gerät /dev/kfd (Kernel Fusion Driver) mit den Berechtigungen zuzugreifen, die für DRI-Geräte gewährt werden, wurde realisiert. Der kfd-Treiber implementiert eine Schnittstelle für die direkte Ausführung von Berechnungen auf AMD-GPUs aus Anwendungen, die AMD ROCm, HIP und OpenCL nutzen.
• Die Unterstützung für die Verwendung von Befehlszeilenoptionen zum Weiterleiten des Zugriffs auf Verzeichnisse in isolierte Anwendungen wurde hinzugefügt.
• Die Unterstützung des Verzeichnisses „preinstall.d“ wurde hinzugefügt, das eine Liste vorinstallierter Flatpak-Anwendungen definiert (um Flatpak-Anwendungen in das Betriebssystem aufzunehmen).
• Die direkte Installation von Anwendungen aus OCI-Containerabbildern, die aus eigenen OCI-Repositories und lokalen Archiven geladen werden können, wurde erlaubt.
• Die Unterstützung für die URI „flatpak+https://“ wurde dem Befehl „flatpak install —from“ hinzugefügt.
• Das Kommando „flatpak run“ wurde um die Option „—clear-env“ erweitert, um Umgebungsvariablen vor dem Start der Anwendung zu löschen.
• Damit wird die Möglichkeit geboten, das Wurzelverzeichnis der Host-Umgebung in eine isolierte Anwendungsumgebung zu exportieren, über das Verzeichnis /run/host/root zugänglich.
• Es wurde die Möglichkeit hinzugefügt, die Ergebnisse der Befehlsausführung im JSON-Format auszugeben.
• Die Isolierung der Build-Umgebung wurde verstärkt – das Kommando „flatpak build“ gewährt standardmäßig keinen Zugriff auf den Host.
• Es wurde der Befehl „reinstall“ zur Neuinstallation von Abhängigkeiten (Bundles) hinzugefügt.
• Die D-Bus-Einstellungen wurden standardmäßig von /etc nach /usr verschoben.
• Die Startzeit beim Einsatz des Kommandos „fish“ wurde verkürzt.
• In libflatpak wurde eine Funktion hinzugefügt, um Informationen über die Erstellungszeit der Konfiguration abzurufen, wodurch Anwendungen wie GNOME Software feststellen können, dass ihre zwischengespeicherten Daten aktualisiert werden müssen.
• Die Build-Option http_backend wurde entfernt; anstelle von libsoup2 wird nun die Bibliothek libcurl für HTTP/HTTPS-Downloads verwendet.
• Die Verwendung von Escape-Sequenzen zur Anzeige des Fortschritts der Operationen ist standardmäßig aktiviert.
• Es wurde ermöglicht, Zugriffsrechte für Geräte an verschachtelte Sandbox-Umgebungen zu übergeben, die über Flatpak-Portale erstellt wurden.
• Für Anwendungen, die als OCI-Images bereitgestellt werden, wurde ein Mechanismus für „extra-data“ implementiert, der beispielsweise die Wiedergabe von h.265-Videos in Flatpak-Paketen von Fedora Linux ermöglicht.
• Es wurde die Unterstützung für die Komprimierung von Abhängigkeiten (OCI-Bundle) mit dem Algorithmus zstd hinzugefügt, der Daten effizienter komprimiert. Standardmäßig wird weiterhin gzip für die Komprimierung verwendet, was maximale Kompatibilität gewährleistet.

Flatpak vereinfacht die Verbreitung von Anwendungen, die nicht in die Standard-Repositories von Distributionen aufgenommen werden, indem es einen universellen Container vorbereitet, der Entwicklern die Notwendigkeit nimmt, separate Builds für jede Distribution zu erstellen. Nutzern, die Wert auf Sicherheit legen, ermöglicht Flatpak, zweifelhafte Anwendungen in einem Container auszuführen, wobei nur selektiver Zugriff auf erforderliche Netzwerkfunktionen und Benutzerdateien gewährt wird. Nutzern, die an Neuigkeiten interessiert sind, erlaubt Flatpak, die neuesten Test- und stabilen Versionen von Anwendungen zu installieren, ohne Änderungen am System vornehmen zu müssen. Beispielsweise werden Flatpak-Pakete für LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio usw. erstellt.

Um die Größe zu reduzieren, werden nur anwendungsspezifische Abhängigkeiten in das Paket einbezogen. Grundlegende System- und Grafikbibliotheken (GTK, Qt, GNOME- und KDE-Bibliotheken usw.) werden als Plug-in-Standard-Runtime-Umgebungen bereitgestellt. Der entscheidende Unterschied zwischen Flatpak und Snap besteht darin, dass Snap Komponenten der Hauptsystemumgebung und Isolation auf Basis von Systemaufruf-Filtern verwendet, während Flatpak einen vom System getrennten Container erstellt und große Runtime-Sets verwendet, die als Abhängigkeiten keine Pakete, sondern Standard-Systemumgebungen bereitstellen (z. B. alle Bibliotheken, die für die Ausführung von GNOME- oder KDE-Anwendungen erforderlich sind).

Neben der Standard-Systemumgebung (Runtime), die über ein spezielles Repository installiert wird, werden zusätzliche Abhängigkeiten (Bundle) bereitgestellt, die für die Ausführung der Anwendung erforderlich sind. Zusammen bilden «Runtime» und «Bundle» die Inhalte des Containers, wobei «Runtime» separat installiert und mehreren Containern zugeordnet wird, was die doppelte Speicherung gemeinsamer Systemdateien für die Container überflüssig macht.

In einem System können mehrere verschiedene „Runtime“ (GNOME, KDE) oder mehrere Versionen einer „Runtime“ (GNOME 50, GNOME 49) installiert werden. Ein Container mit einer Anwendung verwendet als Abhängigkeit die Bindung nur an eine bestimmte „Runtime“, ohne die einzelnen Pakete zu berücksichtigen, die die gewählte „Runtime“ bilden. Alle fehlenden Elemente werden direkt zusammen mit der Anwendung verpackt. Bei der Erstellung des Containers wird der Inhalt der „Runtime“ als das Verzeichnis /usr montiert, und das „Bundle“ wird im Verzeichnis /app gemountet.

Die Zusammensetzung der „Runtime“ und der Anwendungscontainer erfolgt mit der Technologie OSTree, bei der das Abbild atomar aus einem Git-ähnlichen Repository aktualisiert wird, das es ermöglicht, Versionskontrollmethoden auf die Komponenten der Distribution anzuwenden (zum Beispiel kann das System schnell auf einen früheren Zustand zurückgesetzt werden). RPM-Pakete werden über eine Schicht rpm-ostree in das OSTree-Repository überführt.

Die selektive Installation und Aktualisierung von Paketen im Arbeitsumfeld wird nicht unterstützt — das System wird nicht auf der Ebene einzelner Komponenten, sondern vollständig aktualisiert, indem es atomar seinen Zustand ändert. Es stehen Mittel zur Verfügung, um inkrementelle Updates anzuwenden, die eine vollständige Ersetzung des Abbilds bei jedem Update überflüssig machen.

Die gebildete isolierte Umgebung ist unabhängig von der verwendeten Distribution und hat bei entsprechender Paketkonfiguration keinen Zugriff auf die Dateien und Prozesse des Benutzers oder des Hauptsystems und kann außerdem nicht direkt auf Hardware zugreifen, mit Ausnahme der Ausgabe über DRI. Die Ausgabe von Grafiken und die Eingabeverwaltung werden durch das Protokoll Wayland oder durch die Weiterleitung des X11-Sockets realisiert. Die Interaktion mit der externen Umgebung erfolgt über das DBus-Messaging-System und eine spezielle API Portals.

Zur Isolation wird eine Schicht namens Bubblewrap und traditionelle Linux-Container-Virtualisierungstechnologien verwendet, die auf der Nutzung von cgroups, Namensräumen (Namespaces), Seccomp und SELinux basieren. Bei der Erstellung eines Pakets kann die Isolation deaktiviert werden, was von Entwicklern bestimmter Pakete genutzt wird, um vollen Zugriff auf das Dateisystem und alle Geräte im System zu erhalten.

Quelle: opennet.ru