C'est un peu l'actualité du moment dans le monde des distributions GNU/Linux : des nouvelles méthodes d'empaquetage d'application débarquent sur à peu près toutes les distributions et sont annoncées comme révolutionnaires. Mais qu'en est-il vraiment ?

Je vous préviens tout de suite, je ne suis pas un expert dans ce domaine et il se peut qu'il y ait quelques imprécisions. J'ai essayé de me renseigner au maximum avant d'écrire cet article afin de ne pas trop écrire d'aberrations, mais je n'ai pas fait une étude approfondie du code source pour être sûr de ce que j'avance. De toute façon même si je le voulais je n'en aurais pas les capacités. ;) Mais surtout n'hésitez pas à apporter des précisions dans les commentaires, dans d'autres articles, etc.

Dans cet article, je ne parlerai que de deux types de paquets dits "universels" :

  • Flatpak, proposé par freedesktop.org (un projet chargé de proposer des solutions pour favoriser l'interopérabilité dans le secteur des environnements de bureaux libres) ;
  • Snap, proposée par Canonical (la société derrière Ubuntu).

L'existence même des ces types de paquet repose sur la volonté de lancer les applications dans des "bacs à sable". Il s'agit en fait d'isoler les applications du système d'exploitation. L'application évolue de façon autonome et les interactions avec le système hôte ne sont possibles qu'en cas d'accord explicite de la part de l'utilisateur/administrateur. Cela reprend un peu le fonctionnement des applications, Android, iOS qui demandent par exemple la permission d'utiliser la webcam, ou la connexion réseau.

Commençons déjà par décrire le fonctionnement de Flatpak, un poil plus conventionnel que Snap à mes yeux. Accrochez-vous, mais sachez que si vous comprenez la méthodologie utilisée par Flatpak, vous comprendrez le fonctionnement de Snap.

Flatpak repose sur une approche basée sur 2 couches :

  • les runtimes ;
  • l'application.

Un runtime peut être vu comme une librairie partagée et étendue. Alors pourquoi étendue ? Car en plus de la communication vers le système d'exploitation (comme cela se fait actuellement), le runtime est aussi chargé de gérer les accès vers le système hôte. Il est chargé d'ouvrir tel ou tel droit (comme l'accès au réseau, aux fichiers de l’utilisateur) aux applications qui utiliseront ce runtime.

Le paquet à proprement parler intègre l'application mais aussi toutes ses dépendances annexes. Il faut bien comprendre que seul un runtime peut-être partagé entre plusieurs applications. Toutes les autres dépendances doivent être intégrées de façon brute au paquet.

Prenons l'exemple de l'installation de Firefox (en version Gtk idéalement) par le biais d'un paquet Flatpak. Firefox nécessitera le runtime org.gnome.Platform 3.xx (qui propose Gnome SDK) pour les accès au réseau, ainsi que la bibliothèque Gtk (ce qui permet d'alléger l'application). Bien sûr l'idée est aussi de pouvoir gérer de façon précise les droits en verrouillant/déverrouillant certains accès comme bon vous semble. Le fait de baser une application sur un certain runtime, ne donne pas accès à tout les droits gérés par ce runtime. Imaginez maintenant que vous vouliez que la langue de Firefox s'adapte à votre locale. Alors l'application Firefox devra également se baser sur le runtime org.gnome.Locale 3.xx qui se chargera de gérer les accès à la locale du système. Toutes les autres dépendances de Firefox (SQLite, ffmpeg, mesa, python, etc.) sont directement intégrées au paquet et ne pourront pas être partagées avec une autre application.

Dernier point concernant Flatpak, il est actuellement impossible de faire communiquer deux paquets ensemble. Dans le cas de LibreOffice et de son utilisation via Flatpak, il est par exemple impossible d'ouvrir un navigateur via un clic sur un lien hypertexte présent dans un document. De même, il est impossible d'accéder à une aide en ligne, ou même une aide locale sous forme html sans intégrer un moteur de rendu html... Vous sentez venir les emmerdes non ?

Pour ce qui est de Snap, le fonctionnement est légèrement différent. Chaque package comprend l'application ainsi que l'intégralité de ses dépendances, enfin jusqu'à un certain niveau (vous allez comprendre après la lecture des prochains paragraphes), afin de fonctionner en totale indépendance.

En revanche, il existe des paquets Snap un peu spéciaux. Ces paquets ne sont pas des applications (qui je le rappelle fonctionnent en toute indépendance les unes envers les autres) mais des "frameworks". En fait il s'agit d'extensions au système initial (ubuntu-core pour le moment) qui ont des privilèges un peu spéciaux. On va dire que les frameworks sont relativement libres. Les applications communiquent ensuite directement avec ce framework et la gestion des droits se fait donc entre les Snaps "applications" et les Snaps "framework". Comme framework disponible sur Snappy Ubuntu Core, il y a par exemple Docker. Vous commencez à comprendre le truc ? On peut finalement voir de grandes similitudes entre les frameworks de Snap et les runtimes de Flatpak, mais à différents niveaux (Flatpak pour le bureau, Snap pour des services).

À noter que le logiciel chargé de communiquer directement avec le système d'exploitation est lui même considéré comme un paquet Snap. Mais il est spécial dans le sens que les frameworks se basent dessus, et que des applications peuvent également s'en servir comme base. Pour l'instant il n'existe que "ubuntu-core" mais ces derniers jours l'annonce a été faite que Snap serait adapté à la majorité des grandes distributions GNU/Linux.

Cependant, à la différence de Flatpak, il est possible de faire communiquer différents Snaps entre eux via un système d'interfaces. Un Snap peut proposer un "slot" (voyez cela comme la prise dans le mur), tandis que les autres snaps ont la possibilité d'utiliser ce slot pour s'y brancher et démarrer des communications (en utilisant une fiche adaptée à la prise). En listant les interfaces, il est alors possible de visionner l'ensemble des "slots" ainsi que les "plugs" (paquets connectés) associés. Il faut bien comprendre que chaque application basée sur un paquet Snap est capable de se lancer de façon totalement autonome, mais peut cependant communiquer avec les autres applications via un système normalisé permettant un contrôle fin des droits.

Voilà pour le fonctionnement. Si je pouvais résumer les similitudes et les différences je dirai que les deux types de paquets que j'ai présenté sont donc capables de lancer des applications de façon sécurisée (bac à sable) et avec un contrôle précis des droits. Mais Flatpak ne permet pas aux applications de communiquer entre elles, ce qui peut vite devenir embêtant comme on l'a vu avec LibreOffice. Pour les paquets Snap, ceux-ci doivent intégrer l'ensemble des librairies nécessaire à la construction de l'application (pas de liens dynamiques). Ce qui entraîne des tailles de paquet énormes... On repassera donc pour la légèreté des systèmes d'exploitation avec cette méthode...

En fait, après étude de ces nouveaux types de paquets, il me semble que toute cette technologie n'est pas encore assez mature mais semble prometteuse pour certaines applications. L'idéal serait d'arriver à rassembler la légèreté des paquets Flatpak avec les possibilités offertes par les paquets Snap.

Je comprends bien l'intérêt d'avoir des paquets "universels" à des fins de tests ou des applications isolées dans le cadre d'une gestion de serveurs mais je n'arrive pas à comprendre en quoi cela serait "révolutionnaire" et pourquoi cela est présenté comme la méthode d'empaquetage du futur.

Les créateurs de ces paquets insistent bien sur le fait que ces technologies sont complémentaires aux méthodes d'empaquetage "traditionnelles" (rpm, deb, etc.) mais j'ai peur que ces nouvelles méthodes ne soient utilisées à tout bout de champ sans raison valable par les développeurs et en oublient les paquets traditionnels (voir par exemple cet article). Avec Snap et Flatpak il devient très facile de créer son paquet (plus qu'un deb en tout cas) et il y a un effet de "hype" du fait de la nouveauté. Mais franchement, ça n'a quasiment aucun intérêt dans le cas d'une utilisation bureautique. Le seul intérêt concerne la sécurité dans le cas d'une application vérolée... Ce qui reste relativement rare dans le cadre des logiciels libres. J'ai par exemple du mal à saisir l'intérêt de proposer un Snap pour FreeCad. Si ce n'est pour s'amuser...

Mais parlons sécurité justement, car il s'agit bien de l'argument majeur en faveur du déploiement d'applications isolées. Les applications Snap et Flatpak sont empaquetées avec l'ensemble des librairies nécessaires à leur fonctionnement. Ce qui implique que le paquet doit immédiatement être mis à jour lors de la détection d'une faille de sécurité dans une des librairies... Et je ne pense pas que le développeur d'un logiciel proposant son paquet universel pour être tranquille avec le déploiement dans tout l'écosystème GNU/Linux soit plus réactif que des mainteneurs uniquement en charge de la librairie... Imaginez en plus si une faille est découverte dans OpenSSL (toute ressemblance avec un événement réel est purement fortuite). Un administrateur système devra alors s'amuser à chercher tous les paquets ayant empaqueté les versions compromises de OpenSSL (ah oui car en plus, la gestion des versions est totalement libre) pour les désactiver un par un en attendant que tous les créateurs de paquets les remettent à jour... Voilà voilà, je vous laisse méditer là dessus.

J'ai vraiment cherché à me faire une idée de mon côté. En repartant de la base et du fonctionnement de ces nouvelles méthodes d'empaquetage. Et je dois dire que le seul usage que je peux y trouver est un usage de test. On installe une application dans un bac à sable en veillant bien à limiter les droits d'accès au système, on teste un peu, puis on supprime le tout sans laisser de traces. Pour le reste... Très peu pour moi.

J'espère donc que les développeurs ne sauteront pas sur Snap ou Flatpak comme si c'était la solution à tous les problèmes. Restez sur les bonnes vieilles méthodes... S'il vous plaît.