Après un an et demi de développement, une nouvelle branche stable de l'outil Flatpak 1.18 a été publiée. Elle propose un système pour la création de paquets autonomes, indépendants des distributions Linux spécifiques, et s'exécutant dans un conteneur spécial isolant l'application du reste du système. La prise en charge de l'exécution de paquets Flatpak est assurée pour Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux et Ubuntu. Les paquets Flatpak sont inclus dans le dépôt Fedora et sont pris en charge par les gestionnaires d'applications intégrés GNOME et KDE.
Les principales nouveautés de la branche Flatpak 1.18 :
- La prise en charge des permissions conditionnelles a été mise en œuvre, permettant de vérifier la présence de certaines capacités dans le système ou dans le runtime lors de la demande de permissions. Par exemple, lors de l'accès à un dispositif d'entrée, au lieu de «—device=all», il est possible de demander la permission «—device-if=all:!has-input-device —device=input», qui accordera l'accès uniquement aux dispositifs d'entrée ou reviendra à l'accès à tous les dispositifs si la fourniture sélective d'accès n'est pas prise en charge dans le runtime. De la même manière, l'accès aux dispositifs USB peut être demandé («has-usb-device» et «has-usb-portal») ou aux sous-systèmes partagés.
- L'accès à l'appareil /dev/ntsync a été autorisé pour accéder à
au module noyau NTSYNC, qui implémente un ensemble de primitives pour la synchronisation utilisées dans le noyau Windows NT et permettant d'améliorer considérablement les performances des jeux Windows exécutés via Wine. - Pour le GPU Intel Xe, la prise en charge de l'API VA-API pour l'accélération matérielle du décodage vidéo a été ajoutée.
- Il est maintenant possible d'accéder à l'appareil /dev/kfd (Kernel Fusion Driver) en utilisant les permissions fournies pour les dispositifs DRI. Le driver kfd met en œuvre une interface pour effectuer directement des calculs sur le GPU AMD à partir d'applications utilisant AMD ROCm, HIP et OpenCL.
- La prise en charge de l'utilisation d'options de ligne de commande pour le passage d'accès aux répertoires dans les applications isolées a été ajoutée.
- Le répertoire «preinstall.d», qui définit la liste des applications Flatpak préinstallées (pour inclure les applications Flatpak dans le système d'exploitation), a été ajouté.
- L'installation directe d'applications à partir d'images de conteneurs au format OCI, qui peuvent être chargées depuis des dépôts OCI privés et des archives locales, a été autorisée.
- La commande «flatpak install —from» a été étendue pour prendre en charge l'URI «flatpak+https://».
- La commande «flatpak run» a été dotée de l'option «—clear-env» pour nettoyer les variables d'environnement avant le lancement de l'application.
- Il est désormais possible d'exporter le répertoire racine de l'environnement hôte dans un environnement isolé de l'application accessible via le répertoire /run/host/root.
- La possibilité d'afficher le résultat des commandes au format JSON a été ajoutée.
- L'isolement de l'environnement de build a été renforcé : la commande «flatpak build» ne donne désormais pas accès à l'hôte par défaut.
- La commande «reinstall» pour réinstaller les dépendances (bundle) a été ajoutée.
- Les paramètres D-Bus par défaut ont été déplacés du répertoire /etc vers /usr.
- Le temps de démarrage a été réduit lors de l'utilisation de l'interpréteur de commandes fish.
- La fonction pour obtenir des informations sur le temps de création de la configuration a été ajoutée à libflatpak, ce qui permet à des applications comme GNOME Software de déterminer si les données mises en cache nécessitent une mise à jour.
- L'option de compilation http_backend a été supprimée, la bibliothèque libcurl étant maintenant utilisée pour le téléchargement HTTP/HTTPS au lieu de libsoup2.
- L'utilisation des séquences d'échappement pour indiquer la progression de l'opération est activée par défaut.
- Il est désormais possible de transférer les droits d'accès aux appareils vers des environnements sandbox imbriqués créés via des portails Flatpak.
- Pour les applications fournies sous forme d'images OCI, un mécanisme d'«extra-data» a été mis en œuvre, permettant par exemple d'organiser la lecture de vidéos h.265 dans les paquets Flatpak sur Fedora Linux.
- La prise en charge de la compression des dépendances (OCI bundle) utilisant l'algorithme zstd, qui compresse les données de manière plus efficace, a été ajoutée. Par défaut, gzip continue d'être utilisé pour la compression afin d'assurer une compatibilité maximale.
Flatpak facilite la distribution de logiciels ne figurant pas dans les dépôts standard des distributions, en préparant un conteneur universel, évitant ainsi aux développeurs de créer des versions distinctes pour chaque distribution. Pour les utilisateurs soucieux de sécurité, Flatpak permet d'exécuter une application douteuse dans un conteneur, en offrant un accès sélectif uniquement aux fonctions réseau et fichiers nécessaires. Aux utilisateurs intéressés par les nouveautés, Flatpak permet d'installer les dernières versions stables et test des applications sans nécessiter de modifications système. Par exemple, des paquets Flatpak sont disponibles pour LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio, etc.
Pour réduire la taille, le paquet n'inclut que les dépendances spécifiques à l'application. Les bibliothèques système et graphiques de base (GTK, Qt, bibliothèques GNOME et KDE, etc.) sont fournies sous forme d'environnements d'exécution génériques. La principale différence entre Flatpak et Snap réside dans le fait que Snap utilise les composants de l'environnement principal et l'isolation par filtrage des appels système, tandis que Flatpak crée un conteneur distinct du système et gère de larges ensembles d'exécution, fournissant comme dépendances non pas des paquets, mais des environnements système génériques (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 dépôt spécial, des dépendances supplémentaires (bundle) requises pour le fonctionnement de l'application sont fournies. Au total, le « runtime » et le « bundle » constituent le contenu du conteneur, le « runtime » étant installé séparément et pouvant être lié à plusieurs conteneurs, ce qui permet d'éviter la duplication des fichiers système communs à plusieurs conteneurs.
Un système peut avoir plusieurs « runtimes » différents (GNOME, KDE) ou plusieurs versions d'un même « runtime » (GNOME 50, GNOME 49). Un conteneur d'application en tant que dépendance utilise le lien uniquement à un « runtime » spécifique, sans tenir compte des paquets individuels qui forment le « runtime » choisi. Tous les éléments manquants sont empaquetés directement avec l'application. Lors de la création du conteneur, le contenu du « runtime » est monté comme la partition /usr, et le « bundle » est monté dans le répertoire /app.
La structure du « runtime » et des conteneurs d'applications est formée en utilisant la technologie OSTree, où l'image est mise à jour de manière atomique à partir d'un dépôt similaire à Git, permettant d'appliquer des méthodes de contrôle de version aux composants de la distribution (par exemple, il est possible de revenir rapidement à un état précédent du système). Les paquets RPM sont traduits dans le dépôt OSTree à l'aide d'une couche rpm-ostree.
L'installation et la mise à jour sélective des paquets à l'intérieur de l'environnement de travail ne sont pas supportées — le système est mis à jour non pas au niveau de composants individuels, mais dans son intégralité, changeant son état de manière atomique. Des outils sont fournis pour appliquer des mises à jour de manière incrémentale, évitant la nécessité de remplacer complètement l'image à chaque mise à jour.
L'environnement isolé généré ne dépend pas de la distribution utilisée et, avec les paramètres appropriés du paquet, n'a pas accès aux fichiers et processus de l'utilisateur ou du système principal, et ne peut pas accéder directement au matériel, sauf pour la sortie via DRI. La sortie graphique et l'organisation de l'entrée sont réalisées via le protocole Wayland ou par le biais du transfert de socket X11. L'interaction avec l'environnement externe repose sur un système de messagerie DBus et une API Portals spéciale.
Pour l'isolation, une couche Bubblewrap et des technologies de virtualisation de conteneurs traditionnelles sous Linux sont utilisées, basées sur l'utilisation de cgroups, d'espaces de noms (namespaces), de Seccomp et de SELinux. Lors de la création du paquet, l'isolation peut être désactivée, ce dont certains développeurs de paquets profitent pour obtenir un accès complet au système de fichiers et à tous les dispositifs du système.
Source : opennet.ru
