Release des Systems für selbstabschottende Flatpak-Pakete 1.4.0

Veröffentlicht ein neuer stabiler Branch des Tools Flatpak 1.4, der ein System zur Erstellung von eigenständigen Paketen 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 Unterstützung zur Ausführung von Flatpak-Paketen ist für Arch Linux CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint und Ubuntu verfügbar. Flatpak-Pakete sind im Fedora-Repository enthalten und werden in der standardmäßigen GNOME-Anwendungsverwaltung unterstützt.

Schlüssige Neuheiten in der Flatpak 1.4-Version:

  • Die Organisation der Konfigurationseinstellungen für externe Repositories wurde geändert. Im Verzeichnis /etc/flatpak/remotes.d kommen anstelle von *.conf-Dateien mit Einstellungen jetzt reguläre Dateien mit der Erweiterung „.flatpakrepo“ zum Einsatz, die beim ersten Gebrauch von flatpak automatisch importiert werden. Diese Dateien können ebenso wie manuell hinzugefügte Repositories frei bearbeitet und gelöscht werden;
  • Die Organisation der Installationen für die gesamten Systempakete wurde erheblich überarbeitet. In früheren Versionen wurde das Paket zunächst in einem temporären Verzeichnis des Benutzers installiert, gefolgt von einem Systemhelper-Prozess, der das Paket in das System importiert hat. Dieser Ansatz führte zu einem hohen Verbrauch an Speicherressourcen, zusätzlichem I/O und potenziellen Sicherheitsproblemen. In der neuen Version wird für die Installation der Systempakete ein spezielles neues FUSE-Dateisystem verwendet, in das der Benutzer Daten schreiben kann, aber nach Abschluss des Schreibvorgangs wird der Zugriff auf die gespeicherten Dateien für den Benutzer blockiert. Dieser neue Ansatz erfordert die Erstellung eines separaten Benutzers für Flatpak (standardmäßig "flatpak") und Änderungen der SELinux-Regeln.
  • Die Möglichkeit, Filter für externe Repositories auf der Client-Seite zu definieren, wurde hinzugefügt. Mit Hilfe von Filtern kann die Sichtbarkeit der Anwendungen im Repository mithilfe eines Weiß- und Schwarzlistenmodells eingeschränkt werden.
  • Eine Bibliotheks-API zum Hinzufügen externer Repositories aus flatpakref-Dateien wurde hinzugefügt.
  • Ein seccomp-Profil für Docker wurde hinzugefügt, das die Ausführung von flatpak innerhalb von Containern ermöglicht;
  • Die Möglichkeit zur Installation aus mehreren P2P-Quellen (über USB-Sticks oder im lokalen Netzwerk) wurde verbessert;
  • Im Befehl „flatpak remote-ls“ wird die automatische Filterung von Anwendungen sichergestellt, deren Wartungszeit abgelaufen ist;
  • In „flatpak remote-ls“ und „flatpak remote-info“ wurde die Option „—cached“ implementiert, um Informationen auf Basis lokal zwischengespeicherter Daten bereitzustellen;
  • Die Möglichkeit, eine Version für das Ablaufdatum des Pakets anzugeben, nach der ein Vorschlag zur Migration auf einen neuen Branch angezeigt wird, wurde hinzugefügt;
  • Die Option „—socket=pcsc“ wurde hinzugefügt, um Zugriff auf Smartcards zu erhalten;
  • Die Unterstützung für Systeme mit mehreren NVIDIA-Grafikkarten wurde hinzugefügt;
  • Die Unterstützung für dconf, das in einer Sandbox-Umgebung platziert ist, wurde implementiert;
  • Im Befehl build-update-repo wurden die Optionen „—no-update-[summary,appstream]“ und „—static-delta-ignore-ref=PATTERN“ hinzugefügt;
  • Die Geschwindigkeit der Regenerierung von appstream-Branches für große Repositories wurde erheblich verbessert.

Erinnern wir daran, dass Flatpak Anwendungsentwicklern die Möglichkeit bietet, die Verbreitung ihrer Programme zu erleichtern, die nicht in den offiziellen Repositories der Distributionen enthalten sind, indem... Vorbereitung eines universellen Containers ohne separate Builds für jede Distribution. Für Nutzer, die Wert auf Sicherheit legen, ermöglicht Flatpak das Ausführen potenziell unsicherer Anwendungen in einem Container, der nur Zugriff auf das Netzwerk und die mit der Anwendung verbundenen Benutzerdaten gewährt. Für Interessierte an Neuheiten lässt Flatpak die Installation der aktuellsten Test- und stabilen Versionen von Anwendungen zu, ohne dass Änderungen am System erforderlich sind. Derzeit werden bereits Flatpak-Pakete zusammengestellt für LibreOffice, Firefox, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio usw.

Um die Paketgröße zu reduzieren, umfasst es nur anwendungsspezifische Abhängigkeiten, während grundlegende System- und Grafikbibliotheken (wie Gtk+, Qt, sowie GNOME- und KDE-Bibliotheken usw.) in Form von verbindlichen Standard-Runtime-Umgebungen bereitgestellt werden. Ein grundlegender Unterschied zwischen Flatpak und Snap besteht darin, dass Snap die Komponenten der Hauptsystemumgebung nutzt und eine Isolierung mithilfe von Systemaufruf-Filtering durchführt, während Flatpak einen vom System separaten Container erstellt und mit umfangreichen Runtime-Sets arbeitet, die nicht als Pakete, sondern als standardisierte Systemumgebungen bereitgestellt werden (zum Beispiel alle Bibliotheken, die zur Ausführung von GNOME- oder KDE-Anwendungen erforderlich sind).

Neben der standardisierten Systemumgebung (Runtime), die über einen speziellen Repository, werden zusätzliche Abhängigkeiten (Bundle) bereitgestellt, die für den Betrieb der Anwendung erforderlich sind. Zusammen bilden Runtime und Bundle die Grundlage des Containers, wobei die Runtime separat installiert wird und mehreren Containern zugeordnet werden kann. Dies ermöglicht die Vermeidung von Duplizierung gemeinsamer Systemdateien für die Container. In einem System können mehrere verschiedene Runtimes (GNOME, KDE) oder mehrere Versionen einer Runtime (GNOME 3.26, GNOME 3.28) installiert sein. Der Container mit der Anwendung als Abhängigkeit verwendet die Bindung nur zu einer bestimmten Runtime, ohne die einzelnen Pakete zu berücksichtigen, aus denen die Runtime besteht. Alle fehlenden Elemente werden direkt zusammen 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 Grundlage der Runtime und der Anwendungscontainer wird mithilfe von Technologien erstellt. OSTree, bei dem das Abbild atomar aus einem Git-ähnlichen Repository aktualisiert wird, was es ermöglicht, Versionierungsmethoden 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 spezielle Schicht in das OSTree-Repository übertragen. rpm-ostree. Eine separate Installation und Aktualisierung von Paketen innerhalb der Arbeitsumgebung wird nicht unterstützt, das System wird nicht auf der Ebene einzelner Komponenten, sondern in Gänze aktualisiert, wobei der Zustand atomar geändert wird. Es stehen Werkzeuge zur Verfügung, die inkrementelle Aktualisierungen ermöglichen und die vollständige Ersetzung des Abbilds bei jeder Aktualisierung überflüssig machen.

Die gebildete isolierte Umgebung ist vollständig unabhängig von der verwendeten Distribution und hat bei ordnungsgemäßer Paketkonfiguration keinen Zugriff auf die Dateien und Prozesse des Benutzers oder des Hauptsystems; sie kann nicht direkt auf die Hardware zugreifen, außer über DRI-Ausgabe und die Netzwerksubsysteme. Die Ausgabe von Grafiken und die Eingabeorganisation. wurde durch das Wayland-Protokoll oder über den X11-Socket-Forwarding. Die Interaktion mit der Außenwelt basiert auf dem DBus-Nachrichtenaustauschsystem und einer speziellen API für Portale. Zur Isolation genutzt. Schicht Bubblewrap und die traditionellen Linux-Technologien zur Container-Virtualisierung, die auf cgroups, Namespaces, Seccomp und SELinux beruhen. Für die Audioausgabe wird PulseAudio verwendet.

Quelle: opennet.ru

Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server 🔥 Kaufen Sie zuverlässiges Hosting für Websites mit DDoS-Schutz, VPS VDS-Server | ProHoster