Une nouvelle branche stable de la boîte à outils Flatpak 1.14 a été publiée, qui fournit un système permettant de créer des packages autonomes qui ne sont pas liés à des distributions Linux spécifiques et exécutés dans un conteneur spécial qui isole l'application du reste du système. La prise en charge de l'exécution des packages Flatpak est fournie pour Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux et Ubuntu. Les packages Flatpak sont inclus dans le référentiel Fedora et sont pris en charge par le gestionnaire d'applications natif GNOME.
Innovations clés dans la branche Flatpak 1.14 :
- Il est possible de créer un répertoire pour les fichiers en état (.local/state) et de définir la variable d'environnement XDG_STATE_HOME pointant vers ce répertoire.
- Ajout de vérifications conditionnelles du formulaire « have-kernel-module-name » pour déterminer la présence de modules du noyau (un analogue universel de la vérification have-intel-gpu proposée précédemment, au lieu de laquelle l'expression « have-kernel-module-i915 » peut désormais être utilisé).
- La commande « flatpak document-unexport —doc-id=… » a été implémentée.
- L'exportation des métadonnées Appstream pour une utilisation dans l'environnement principal est fournie.
- Ajout des règles d'achèvement des commandes flatpak pour la coquille de poisson
- L'accès réseau aux services X11 et PulseAudio est autorisé (si les paramètres appropriés sont ajoutés).
- La branche principale du référentiel Git a été renommée de « master » à « main », puisque le mot « master » a récemment été considéré comme politiquement incorrect.
- Les scripts de lancement sont désormais réécrits si l'application est renommée.
- Ajout des options "--include-sdk" et "--include-debug" à la commande d'installation pour installer les fichiers SDK et debuginfo.
- Ajout de la prise en charge du paramètre "DeploySideloadCollectionID" aux fichiers flatpakref et flatpakrepo. Lorsqu'il est défini, l'ID de collection sera défini lors de l'ajout d'un référentiel distant, et non après le chargement des métadonnées.
- Autorisé la création d'environnements sandbox imbriqués pour les gestionnaires dans les sessions avec des noms MPRIS (Media Player Remote Interfacing Spécification) distincts.
- Les utilitaires de ligne de commande fournissent désormais des informations sur l'utilisation d'extensions d'exécution obsolètes.
- La commande de désinstallation implémente une demande de confirmation avant de supprimer le runtime ou les extensions d'exécution encore utilisées.
- Ajout de la prise en charge de l'option « --socket=gpg-agent » pour les commandes telles que « flatpak run ».
- Une vulnérabilité a été corrigée dans libostree qui pourrait potentiellement permettre à un utilisateur de supprimer des fichiers arbitraires sur le système via la manipulation du gestionnaire flatpak-system-helper (envoi d'une demande de suppression avec un nom de branche spécialement formaté). Le problème n'apparaît que dans les anciennes versions de Flatpak et libostree publiées avant 2018 (< 0.10.2) et n'affecte pas les versions actuelles.
Rappelons que Flatpak permet aux développeurs d'applications de simplifier la distribution de leurs programmes qui ne sont pas inclus dans les référentiels de distribution standard en préparant un conteneur universel sans créer d'assemblys séparés pour chaque distribution. Pour les utilisateurs soucieux de leur sécurité, Flatpak vous permet d'exécuter une application douteuse dans un conteneur, donnant accès uniquement aux fonctions réseau et aux fichiers utilisateur associés à l'application. Pour les utilisateurs intéressés par les nouveaux produits, Flatpak vous permet d'installer les dernières versions de test et stables des applications sans avoir besoin d'apporter des modifications au système. Par exemple, les packages Flatpak sont conçus pour LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
Pour réduire la taille du package, il inclut uniquement les dépendances spécifiques à l'application, et les bibliothèques système et graphiques de base (bibliothèques GTK, Qt, GNOME et KDE, etc.) sont conçues comme des environnements d'exécution standard de plug-in. La principale différence entre Flatpak et Snap est que Snap utilise les composants de l'environnement système principal et une isolation basée sur le filtrage des appels système, tandis que Flatpak crée un conteneur séparé du système et fonctionne avec de grands ensembles d'exécution, fournissant non pas des packages en tant que dépendances, mais des packages standard. leurs environnements système (par exemple, toutes les bibliothèques nécessaires au fonctionnement des programmes GNOME ou KDE).
En plus de l'environnement système standard (runtime), installé via un référentiel spécial, des dépendances supplémentaires (bundle) nécessaires au fonctionnement de l'application sont fournies. Au total, le runtime et le bundle constituent le remplissage du conteneur, malgré le fait que le runtime soit installé séparément et lié à plusieurs conteneurs à la fois, ce qui permet d'éviter la duplication des fichiers système communs aux conteneurs. Un système peut avoir plusieurs environnements d'exécution différents installés (GNOME, KDE) ou plusieurs versions du même environnement d'exécution (GNOME 3.40, GNOME 3.42). Un conteneur avec une application comme dépendance utilise une liaison uniquement avec un runtime spécifique, sans prendre en compte les packages individuels qui composent le runtime. Tous les éléments manquants sont emballés directement avec l'application. Lorsqu'un conteneur est formé, le contenu du runtime est monté en tant que partition /usr et le bundle est monté dans le répertoire /app.
Les conteneurs d'exécution et d'application sont construits à l'aide de la technologie OSTree, dans laquelle l'image est mise à jour atomiquement à partir d'un référentiel de type Git, ce qui permet d'appliquer des méthodes de contrôle de version aux composants de distribution (par exemple, vous pouvez rapidement restaurer le système vers un état précédent). Les packages RPM sont traduits dans le référentiel OSTree à l'aide d'une couche spéciale rpm-ostree. L'installation et la mise à jour séparées des packages dans l'environnement de travail ne sont pas prises en charge ; le système n'est pas mis à jour au niveau des composants individuels, mais dans son ensemble, modifiant atomiquement son état. Fournit des outils pour appliquer les mises à jour de manière incrémentielle, éliminant ainsi le besoin de remplacer complètement l’image à chaque mise à jour.
L'environnement isolé généré est totalement indépendant de la distribution utilisée et, avec les paramètres appropriés du package, n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, ne peut pas accéder directement à l'équipement, à l'exception de la sortie via DRI, et les appels au sous-système réseau. La sortie graphique et l'organisation des entrées sont implémentées à l'aide du protocole Wayland ou via le transfert de socket X11. L'interaction avec l'environnement externe est basée sur le système de messagerie DBus et une API spéciale Portals.
Pour l'isolation, la couche Bubblewrap et les technologies traditionnelles de virtualisation de conteneurs Linux sont utilisées, basées sur l'utilisation de groupes de contrôle, d'espaces de noms, Seccomp et SELinux. PulseAudio est utilisé pour produire du son. Dans ce cas, l'isolation peut être désactivée, ce qui est utilisé par les développeurs de nombreux packages populaires pour obtenir un accès complet au système de fichiers et à tous les périphériques du système. Par exemple, GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity et VLC sont dotés d'un mode d'isolation limité qui laisse un accès complet au répertoire personnel. Si des packages ayant accès au répertoire personnel sont compromis, malgré la présence du label « sandboxed » dans la description du package, l'attaquant n'a qu'à modifier le fichier ~/.bashrc pour exécuter son code. Un autre problème est le contrôle des modifications apportées aux packages et la confiance dans les générateurs de packages, qui ne sont souvent pas associés au projet principal ou aux distributions.
Source: opennet.ru