L’avenir de Flatpak

• Flatpak gagne actuellement en popularité auprès des développeurs et des utilisateurs, mais le projet lui-même fait face à un problème de stagnation du développement
• Le départ de développeurs clés et des goulots d’étranglement entraînent des retards dans l’intégration de nouvelles fonctionnalités et les revues de code
• Diverses améliorations ont été proposées, comme la prise en charge des images OCI, la granularité des permissions et le contrôle d’accès audio, mais leur intégration effective progresse lentement
• Pour le développement à long terme du projet, l’adoption du standard des technologies de conteneurs (OCI) et une réimplémentation en Rust sont envisagées
• La résolution de problèmes majeurs comme l’amélioration des portails, la prise en charge des pilotes et le sandboxing réseau sera déterminante pour la croissance de Flatpak

---

Présentation générale et état actuel du projet Flatpak

• Flatpak a commencé en 2007 sous la forme d’un projet similaire, a connu une première sortie en 2015 sous le nom de XDG-App, puis a été renommé Flatpak en 2016
• Il fournit des outils en ligne de commande, des outils de build et des composants d’exécution, et s’appuie sur cgroups, namespaces, bind mount, seccomp, Bubblewrap, etc., pour assurer l’isolation des applications (sandboxing)
• OSTree est le mécanisme de distribution par défaut, et plus récemment la prise en charge des images OCI a aussi été ajoutée et utilisée notamment dans Fedora
• Le succès de Flathub, la croissance de la boutique d’applications et l’adoption par des distributions sont réels, mais le projet connaît en interne un ralentissement du développement actif

Stagnation du développement et causes principales

• Les activités de maintenance et de correctifs de sécurité continuent, mais le développement de grandes nouvelles fonctionnalités et les revues de code sont bloqués depuis longtemps
• Le départ de développeurs majeurs (comme Larsson) a réduit le nombre de relecteurs, rendant plus difficile l’arrivée de nouveaux contributeurs ou l’intégration de changements d’ampleur
• Même des fonctionnalités comme l’installation préalable de Flatpak (Preinstall), sur lesquelles contribuent Red Hat et d’autres, ont connu à plusieurs reprises des délais de plusieurs mois avant intégration à cause du retard des revues et du départ de responsables

OSTree et prise en charge des images OCI

• OSTree a été appliqué avec succès à Flatpak, mais son caractère non standard et son outillage limité font qu’il n’évolue guère au-delà de la maintenance
• OCI bénéficie d’un large écosystème d’outils pour les images de conteneurs, ce qui permettrait à l’équipe Flatpak de réduire la charge de maintenance et les efforts redondants en l’adoptant
• La prise en charge de formats de compression efficaces comme zstd:chunked a aussi été proposée via de nouvelles PR, mais reste retardée et non intégrée

Gestion des permissions et granularité du sandbox

• Flatpak met l’accent sur la limitation de l’accès système par le sandboxing, et les versions récentes prennent en charge une granularité plus fine des permissions (par exemple --device=input)
• Les versions de Flatpak diffèrent selon les distributions Linux, ce qui crée des problèmes de diffusion limitée des nouvelles permissions et de compatibilité entre versions
• Pour les permissions audio, les limites de PulseAudio compliquent la séparation entre lecture et enregistrement, d’où la nécessité d’améliorations via PipeWire ou des solutions similaires
• Le support insuffisant du sandboxing imbriqué empêche des applications comme les navigateurs web d’utiliser en interne leur propre sandbox distinct

D-Bus et sandboxing réseau

• Flatpak n’accède pas directement à D-Bus, mais utilise xdg-dbus-proxy pour une communication filtrée
• Wick souhaite déplacer la politique de filtrage vers le broker D-Bus afin de permettre une application dynamique des politiques et un contrôle d’accès basé sur les cgroups
• L’implémentation incomplète des namespaces réseau laisse subsister la possibilité de communications non intentionnelles entre applications Flatpak lorsqu’un port localhost est exposé (cas réel : AusweisApp)
• Les pilotes NVIDIA sont fournis séparément pour chaque runtime, ce qui entraîne un trafic réseau excessif et des mises à jour difficiles. Des pistes comme le partage depuis l’hôte et la compilation statique, inspirées du modèle de Valve, sont étudiées

Usage des portails et nécessité d’amélioration

• Les portails sont des API d’accès à des ressources externes basées sur D-Bus, utilisées pour les fichiers, l’impression, les URL et bien d’autres fonctions
• Des portails comme Documents sont efficaces à l’échelle du fichier, mais pour des applications à fort enjeu d’ergonomie comme GIMP ou Blender, un modèle de permissions trop fin devient une limite
• En parallèle de propositions de nouvelles API pour le remplissage automatique de mots de passe, les clés FIDO ou la synthèse vocale, des idées sont discutées pour réduire la difficulté de développement, notamment une réimplémentation en Rust

L’avenir de Flatpak (Flatpak-next)

• En partant de l’hypothèse où Flatpak cesserait d’être développé sous sa forme actuelle, une transition majeure vers l’écosystème OCI (images, registres, outils, politiques, etc.) est discutée dans une perspective de long terme
• Une réimplémentation en Rust et une unification avec l’écosystème des conteneurs pourraient apporter des avantages en matière de charge de gestion, de maintenance et d’évolutivité

Résumé des questions-réponses

• À la question de savoir comment seraient gérées les applications Flatpak existantes en cas de transition vers OCI, il a été répondu que l’automatisation du build sur Flathub éviterait de gros problèmes
• Concernant le manque de métadonnées dans les registres OCI, des standards pour des données non liées aux images sont en cours d’élaboration, mais leur adoption réelle demandera encore du développement et de l’intégration
• À propos d’un support direct de PipeWire, des discussions techniques sont en cours, avec une orientation vers une intégration fondée sur les politiques de PipeWire

Conclusion

• Flatpak s’est imposé comme une plateforme standard de distribution et de sandboxing, mais reste confronté à plusieurs chantiers d’amélioration : stagnation des revues et du nouveau développement, problèmes de permissions, de réseau et de pilotes, ainsi qu’évolution vers de futurs standards
• L’usage des technologies de conteneurs basées sur OCI et de Rust pourrait devenir un nouveau moteur pour l’évolution de Flatpak
• Les points clés se résument à la disponibilité de relecteurs, la standardisation, l’extension de l’écosystème et l’amélioration de l’expérience utilisateur

[ndrgrd]

Je pense qu’au lieu de bloquer complètement les autorisations d’accès, il vaudrait mieux montrer clairement à quels répertoires l’application accède.

Android est plutôt correct sur ce point, mais de ce côté-là les autorisations sont trop largement regroupées, donc il faut aussi autoriser des permissions à un niveau dont on n’a pas besoin...

[GN⁺]

Avis sur Hacker News

• Partage d’un point souligné dans la présentation de Wick : le projet Flatpak semble fonctionner correctement en apparence, mais en réalité il ne bénéficie pas d’un développement actif ; la maintenance de sécurité et l’entretien minimal se poursuivent, mais presque aucune nouvelle fonctionnalité n’est ajoutée. Le fait que de nombreuses propositions de fonctionnalités (Merge Requests) restent bloquées faute de relecteurs est jugé problématique. Avec l’arrêt des paquets desktop dans RHEL 10 et la recommandation d’installer les paquets via Flathub, le rôle de Red Hat est devenu encore plus important. Si Red Hat veut vraiment faire de Flatpak une alternative crédible, il devrait y consacrer davantage de ressources. Accord aussi avec l’observation de Wick selon laquelle la prise en charge de nouvelles permissions varie selon les versions de Flatpak, ce qui impose de préserver la backwards compatibility. L’auteur l’a constaté directement en distribuant un jeu sur Flathub : problèmes de permissions audio et manette, absence de prise en charge de --device=input, impossibilité d’ouvrir uniquement les haut-parleurs tout en bloquant le micro, etc.
  • Mention d’un cas où Red Hat avait initialement prévu de distribuer Firefox et Thunderbird sur RHEL 10 uniquement en Flatpak, avant de finalement fournir aussi des paquets rpm après la sortie GA. Plusieurs raisons se sont combinées : absence de prise en charge de Native Messaging, impossibilité de déployer des politiques centralisées, problèmes d’intégration desktop, etc.
• Partage d’une expérience personnelle : lors des débuts de Flatpak, l’auteur a rencontré directement son développeur initial et discuté de sa philosophie de conception. Il a essayé d’expliquer que le fait de lier les permissions au nom du paquet, sans isolation par instance, posait problème. En d’autres termes, il n’est pas possible de lancer plusieurs instances de la même application Flatpak avec des permissions différentes, par exemple en n’autorisant pour l’une qu’un sous-répertoire spécifique de Documents. Selon lui, MS, Apple App Store et macOS suivent la même logique, et tout le monde a donc mal conçu le système. Par exemple, même si une RCE (exécution de code à distance) se produit dans un document LibreOffice, l’accès à ses autres documents devrait rester bloqué ; le sandbox Flatpak devrait assurer cette sécurité même si l’éditeur ne s’en préoccupe pas.
  • Regard critique sur la complexité supplémentaire induite par ces objectifs de sécurité. Comme le PC lui appartient, les permissions par instance, les sandbox et les restrictions de partage de fichiers lui paraissent inutiles, et il souhaite conserver le concept traditionnel selon lequel « tout est fichier ». Il cite par exemple Thunderbird et Firefox, qui ne peuvent pas accéder au répertoire /tmp, ce qui rend l’enregistrement de pièces jointes et leur ouverture dans d’autres applications extrêmement pénibles dans un environnement sandboxé. Selon lui, le propriétaire de l’ordinateur doit être l’utilisateur, non le développeur. Il considère que cet excès de sécurité nuit à la productivité, et le compare à une Useless Machine.
  • Hypothèse selon laquelle l’équipe Flatpak comprenait peut-être ce problème. Si Flatpak avait choisi un modèle techniquement parfait, cela aurait sans doute créé une barrière d’entrée bien trop élevée pour les développeurs d’applications, en particulier multiplateformes, au point d’empêcher la diffusion de Flatpak lui-même.
  • Le modèle de permissions par instance est jugé très séduisant, mais une approche hybride est proposée comme plus pratique : pour la configuration (git config, dossier de polices, etc.), toutes les instances pourraient partager les mêmes droits d’accès via une option dédiée.
  • Il serait souhaitable, selon cet avis, de repenser l’ensemble du système d’exploitation afin d’accorder des capabilities distinctes à chaque instance en cours d’exécution, avec prise en charge de quotas disque, journalisation, proxy, séparation fine des permissions et d’autres fonctions du même type. Le problème ne serait donc pas propre à Flatpak.
  • Pour les power users ou les utilisateurs sensibles à la sécurité, qui ont besoin d’une isolation stricte comme le sandboxing basé sur hyperviseur de QubesOS, la séparation par instance est utile ; mais pour la plupart des usages, une isolation gérée à l’intérieur même de l’application est plus intuitive. Comme pour le sandboxing des navigateurs web, l’idéal serait que Flatpak prenne en charge les nested sandbox, mais ce n’est pas le cas aujourd’hui. Il existe aussi des questions assez complexes autour de l’intégration de la signature de code avec le sandbox, des espaces de noms UID, etc.
• En tant qu’utilisateur de Flatpak de longue date et très enthousiaste, l’auteur estime qu’il a été innovant et a permis d’utiliser facilement des applications récentes sur toutes les distributions Linux, mais constate que, faute d’évolution depuis plusieurs années, son intérêt s’est émoussé. Aujourd’hui, l’AUR lui suffit dans la plupart des cas, et la stagnation de Flatpak lui semble regrettable.
  • À part sa simplicité d’usage côté utilisateur, Flatpak n’a pas vraiment offert une bonne expérience : thèmes, curseurs, sélecteur de fichiers, permissions, Drag&Drop, problèmes d’intégration variés, nécessité d’outils supplémentaires pour certaines fonctions. Si l’UX est médiocre, les bénéfices de sécurité comme le sandboxing perdent leur sens. Sans les problèmes de portabilité binaire sous Linux, Flatpak n’aurait probablement pas été nécessaire.
  • La combinaison Fedora + GNOME + Flatpak a un temps semblé très innovante, mais l’auteur est finalement revenu à Arch. Les dépôts Arch se sont énormément enrichis, au point qu’il a rarement besoin de l’AUR.
  • S’adressant à quelqu’un ayant déjà géré plusieurs paquets, il lui demande son retour d’expérience sur makedeb : basé sur PKGBUILD, makedeb semble très portable, et il trouve étonnant qu’on en parle si peu.
• Sans adhérer à 100 % à la thèse de Drew DeVault selon laquelle « les distributions devraient s’occuper du packaging des applications », l’auteur présente un texte de fond ancien et ce lien de référence. Il défend l’idée que le bon modèle est celui où la communauté (la distribution) gère les paquets au nom des utilisateurs. Les modèles de packaging extérieurs à la distribution, comme Flatpak/Snap/AppImage, sont selon lui fondamentalement mauvais.
  • Réponse contraire : le développeur qui crée directement l’application est le mieux placé pour gérer son packaging, surtout dans le cas des logiciels propriétaires où les droits légaux de distribution et de packaging sont exclusifs. Même pour l’open source, laisser des personnes extérieures à l’équipe principale intervenir arbitrairement dans le packaging entraîne selon lui des bugs inutiles, des retards de release et de nouveaux problèmes. Il veut des mises à jour rapides et récentes, et des logiciels fournis dans leur état d’origine, sans altération du packaging. Le vrai problème de Flatpak serait qu’il cherche à remplir trop de rôles à la fois. Le modèle de l’app store lui-même inspire aussi du scepticisme : sous Windows et macOS, la distribution binaire reste libre sans app store, et la sécurité minimale est assurée au niveau de l’OS, par exemple via la signature de code. Il juge inutile qu’un système de packaging tiers domine l’écosystème.
  • Les développeurs d’applications devraient pouvoir distribuer directement leurs logiciels, en prenant pour exemple la simplicité de l’installation sous Windows. Il est irréaliste d’attendre des mainteneurs qu’ils aient la capacité de prendre en charge toutes les distributions, et cela freine selon lui le développement du desktop Linux.
  • Le fait de devoir empaqueter séparément pour de multiples distributions finit au contraire par faire perdre beaucoup de sens à l’ensemble.
  • Il paraît irréaliste de penser que les distributions pourraient empaqueter tous les logiciels du monde.
  • Partant du constat que les distributions packagent mal les applications, l’auteur se réjouit de l’adoption croissante de Flatpak et estime que les développeurs devraient pouvoir diffuser facilement leurs applications sans intermédiaire.
• Accord avec la critique selon laquelle Flatpak continue de dépendre de PulseAudio et prend du retard sur l’adoption de PipeWire. PulseAudio regroupe les permissions haut-parleurs et microphone sans possibilité de les séparer : dès qu’une application reçoit le droit de sortir du son, elle peut aussi accéder automatiquement au micro, ce qui constitue une faille de sécurité majeure.
  • On voit souvent des utilisateurs Linux se moquer des erreurs de conception ou du manque de liberté sous Windows/macOS, mais il faut aussi reconnaître ce type de problème de conception fondamental. L’écosystème Linux aurait tendance à laisser les problèmes en suspens sans clarifier les responsabilités.
• Installation de VSCode/Codium en Flatpak pour faire du débogage Python : la configuration du débogueur a pris beaucoup de temps à cause de problèmes de permissions et de réglages, puis tous les soucis ont disparu après installation de la version Snap.
  • Flatpak semble adapté aux grosses applications desktop comme Chrome ou Chromium, mais inadapté aux outils système.
  • L’auteur dit n’avoir retiré de la version Flatpak d’Emacs que de l’inefficacité et de la frustration.
• En passant à une immutable distro basée sur Flatpak, l’expérience peut être bonne quand tout fonctionne, mais dans les faits beaucoup plus de choses que prévu ne marchent pas, ce qui déçoit. Sont cités comme exemples l’exécution d’outils externes pour Godot, de nombreux ajustements de permissions, les problèmes d’interopérabilité entre Flatpak (par exemple Firefox et KeepassDX), les crashs de Godot et Krita en Flatpak, ou encore la coexistence avec des environnements hétérogènes non-Flatpak comme AppImage ou .rpm. L’auteur espère voir davantage d’innovation autour de Flatpak.
• La structure de Flatpak rend impossible le packaging d’applications comme Tailscale qui doivent créer des interfaces réseau virtuelles. macOS permet au contraire de détailler les permissions réseau via des API, ce qui permet à Tailscale d’être distribué sur le Mac App Store sous forme d’application sandboxée.
  • Grâce à cette API, la distribution de l’application macOS sandboxée de Tailscale est possible, tandis que sur les distributions Linux « atomic » dépendantes de Flatpak, comme Silverblue ou Bluefin, ce type de logiciel est difficile à utiliser.
  • Flatpak a du sens pour de grosses applications desktop comme OBS Studio, mais pour Tailscale, qui se comporte comme un service système, les paquets natifs de la distribution paraissent plus adaptés. Sur Arch Linux, il existe d’ailleurs un paquet officiel.
  • Des contournements existent avec flatpak-spawn, polkit-exec, etc., mais cela revient presque à renoncer à la protection du sandbox.
  • Vouloir résoudre en une seule couche, au sommet de Linux, à la fois un système de permissions fin et le packaging semble excessivement complexe. Cette complexité pourrait expliquer la stagnation de Flatpak ou l’épuisement de ses développeurs. Comme Linux moderne ne dispose pas d’un véritable modèle fondamental de permissions, la priorité réaliste ne serait pas la perfection du contrôle d’accès, mais plutôt la distribution, le packaging et les mises à jour logicielles.
  • Des logiciels comme Tailscale devraient relever d’un sysext plutôt que de Flatpak, selon cet avis.
• À propos des propositions de distribution via Flatpak : en développant l’application Java KmCaster, l’auteur a reçu des demandes de portage vers Flatpak, mais n’y a vu que des charges supplémentaires — deux méthodes d’installation à maintenir, gestion des statistiques de téléchargement, confiance envers un dépôt tiers, multiplication des gestionnaires de paquets, duplication des dépôts — sans avantage concret.
  • Malgré cela, il reconnaît aussi des aspects positifs à Flatpak : simplicité d’usage sur les immutable distro, disparition du besoin de gérer les versions de Java, visibilité dans la recherche Flathub, mises à jour automatiques, etc.
• Sans être mainteneur open source ni développeur, l’auteur dit ne pas comprendre pourquoi tant de distributions Linux, toutes confrontées aux mêmes problèmes de gestion des paquets, ne s’unissent pas pour améliorer et généraliser Flatpak.
  • Réponse : comme chaque distribution a sa propre manière d’être une distribution, une unification complète est difficile, et la diversité des choix fait justement partie des avantages de l’écosystème open source. Personnellement, l’auteur préfère les gestionnaires de paquets système traditionnels.
  • En suivant cette logique, il ne devrait exister que GNOME ; or la diversité des communautés et des prises de décision est importante.
  • Flatpak ne lui sert absolument à rien, et il ne veut pas qu’on l’oblige à contribuer à un logiciel qu’il n’utilise pas.