Linux domine sans conteste le monde des serveurs et des systèmes embarqués. Pourtant, le marché de l'ordinateur personnel lui a longtemps échappé, solidement verrouillé par Windows pour le jeu et par macOS pour la création de contenu. Depuis 10 ans cependant, le bureau Linux mue grâce à des technologies de standardisation. Si Wayland et PipeWire jouent un rôle important dans cette progression, c'est sur Flatpak que j'aimerais m'attarder aujourd'hui suite à la lecture d'un article intéressant de Yves Auxier.
Comme le souligne très justement l'auteur, pour capter la philosophie de Flatpak, il faut d'abord regarder du côté des serveurs. Dans ce domaine, la stabilité est reine, justifiant souvent l'usage de bibliothèques logicielles ou de noyaux datant de plusieurs années. Les mises à jour fréquentes risquent de casser le système et d'engendrer de précieuses pertes de temps de disponibilité. Pour faire tourner des softs récents sur ces fondations vieillissantes sans compromettre la sécurité, l'industrie a adopté les conteneurs. Ces boîtes isolées embarquent un logiciel avec ses propres dépendances et limitent de manière drastique son accès au système hôte.
Flatpak, né en 2015, n'a fait que transposer cette logique éprouvée au bureau Linux. En s'appuyant sur les Portails et le SDK Freedesktop, il a mis fin au champ de bataille des dépendances conflictuelles pour offrir aux développeurs une plateforme de distribution enfin cohérente, fonctionnant un peu à la manière des environnements limités que l'on retrouve sur Android ou iOS.
Bousculer des décennies de gestion de paquets ne se fait évidemment pas sans heurts. Certains utilisateurs s'accrochent farouchement à l'ancienne méthode, exigeant que chaque logiciel soit re-packagé des centaines de fois pour s'adapter à des milliers de configurations Linux différentes. C'est dans ce contexte que sont apparus des articles alarmistes qualifiant Flatpak de véritable cauchemar sécuritaire. Leur méthodologie est souvent biaisée car ils ciblent de vieilles applications disponibles sur Flathub pour démontrer que le bac à sable de Flatpak serait inopérant.
C'est une inversion totale du problème. Ces dernières ont été conçues pour des environnements non confinés, à une époque où les API modernes n'existaient pas. Si elles requièrent aujourd'hui des permissions statiques étendues pour fonctionner, cela démontre l'insécurité intrinsèque de ces logiciels face aux standards récents et non une faille de la technologie qui les héberge. Flatpak est un bac à sable et il est sécurisé. Ce sont ces applications spécifiques qui ne le sont pas. Blâmer l'infrastructure parce que certains vieux logiciels ont besoin de permissions larges revient à changer la définition même du mot "bac à sable". Plutôt que de rejeter Flatpak, notre énergie devrait être investie dans la transition des développeurs vers ces nouvelles API.
L'efficacité de cette isolation, même lorsqu'elle est imparfaite, s'observe dans des situations bien réelles. Prenons le cas du malware "fractureiser". Lorsqu'on analyse son code, on constate qu'il cible directement le dossier de configuration utilisateur classique et les processus du système central. Pourtant, s'il est exécuté via la version Flatpak du lanceur PrismLauncher, il est neutralisé. Sans les permissions adéquates, ses tentatives d'écriture sont redirigées vers un espace temporaire volatil qui s'efface au redémarrage du bac à sable, et son accès à systemd lui est purement refusé. C'est la preuve irréfutable que le simple fait de lancer des logiciels de confiance ne suffit plus aujourd'hui. L'isolation face aux compromissions de systèmes récents est une nécessité absolue.
Autre argument fréquemment brandi par les détracteurs, la présence présumée de dépendances obsolètes. Cela ne tient pas la route. Le runtime (l'environnement d'exécution de Flatpak) est mis à jour dès qu'un correctif de sécurité est disponible, allant parfois jusqu'à casser la compatibilité binaire si l'urgence l'exige. Les développeurs n'ont plus à gérer manuellement l'intégration de chaque correctif et des composants majeurs comme les pilotes graphiques peuvent être actualisés indépendamment. Même dans l'éventualité où une application utiliserait ponctuellement une bibliothèque vieillissante, l'enceinte du bac à sable est justement là pour contenir et mitiger les risques potentiels.
En lisant ce travail de démystification, je ne peux que rejoindre la conclusion de Yves, l'avenir du bureau Linux passe inévitablement par ces méthodes de distribution pensées pour faciliter la vie des développeurs tout en renforçant la sécurité des utilisateurs. Revenir en arrière pour rassurer les nostalgiques du packaging traditionnel serait un signal désastreux. Cela prouverait au monde du développement que Linux reste une plateforme fragmentée et hostile, condamnant l'expérience de l'utilisateur final. Nous avons fait d'immenses progrès de concert avec des outils comme Wayland ou PipeWire. Flatpak est la pierre angulaire de cette modernisation indispensable.