Bonjour et merci de cet excellente analyse. En tant qu’administrateur de nombreux serveurs sur un réseau dont j’administre et assure l’intégrité global des accès aussi bien vis-à-vis du fournisseur d’accès que des utilisateurs et devant absolument assurer au maximum la sécurité globale du réseau que j'administre mais ne disposant pas des ressources des gros opérateurs (OVH, IONOS, ScaleWay, Google, AMV, Azure, …) je dois bien avouer que je ne peux que dire que le taux de contraintes sur la tenue des serveurs est bien une cote mal taillée. Il faut aussi tenir compte du fait que l’utilisateur final, même s’il connait *nix, n’a souvent que peu de connaissances des conséquences d’une serveur mal sécurisé et a trop souvent l’idée du « ça ne me concerne pas » sans se soucier du fait que ça pourrait bien le concerner directement si son serveur est victime de l’attaque sur le serveur du voisin…
Il y a aussi un point négatif sur les déploiements intégrés : * Le fait qu’on ne peut suivre raisonnablement les N sources d’émission (FlatPack, Snap, AppImage, Docker, …) en fonction des outils utilisés sur chaque serveur. Cela alourdi conséquemment le suivit des serveurs sans en garantir l’intégrité. Quant à l’argument de bibliothèques « ante-dilluviennes » présentes sur les distributions LTS, vous me permettrez de douter de celui-ci. Soit le développement est … en développement, et oui, le fait d’avoir la dernière version d’une bibliothèque peut être importante mais on ne peut présenter ce développement comme opérationnel et distribuable à tous. Soit on souhaite le distribuer en tant qu’opérationnel (professionnel) et là, il est plus sérieux de s’appuyer sur des versions de bibliothèques solides, opérationnelles et stables fournies par la communauté plutôt que le dernier petit bijou dont on ne connait pas véritablement et la stabilité et même finalement l’avenir. Pour un responsable de sécurité, lire comme un argument positif que les containers peuvent être la solution car phagocytées; lire que « S'il est strict et propre, l'application n'a qu'un accès limité au système » hérisse le poil. D’autre part si le développeur gagne du temps et de la sueur en limitant ses distributions il se charge d’une lourde charge de suivit et de mise-à-jour dans l’avenir immédiat. Je suis d’accord sur les conclusions même si je les redoute. Toutes ces réflexions viennent finalement de la faiblesse des ressources humaines disponibles à tous les étages de la construction, du suivit des applications proposées. Le développement « en continu » pourrait être LA solution à la seule condition de savoir positionner le curseur entre ce qu’est un développement d’un passage en version stable. C’est toute la science et le sérieux d’une distribution comme Debian en fait. Mais cela demande … de lourdes ressources humaines, une procédure stricte à la fois de validation et de tests. C’est tout un travail dans l’ombre et peu valorisé ni valorisante. Or, malheureusement, ce n’est pas toujours le cas des modules en développement et pas parce que ces développeurs ne sont pas sérieux. En tout cas merci à vous pour ce point de vue explicite et circonstancié. > Le 9 juin 2025 à 23:36, Sébastien Dinot <[email protected]> a écrit : > > Bonjour, > > Alex PADOLY a écrit : >> Quelle est l'utilité de SNAP? >> Je trouve que Debian gère très bien les paquets. > > Grosso modo, le déploiement d'une application peut s'envisager de deux > manières bien différentes : > > * Déploiement intégré (au système hôte) : l'application a été conçue et > compilée pour fonctionner avec les bibliothèques disponibles > nativement sur le système hôte. Dans ce cas, le « paquet » de > l'application ne fournit que l'application et les ressources externes > associées (documentation, fichiers de configuration, icônes et autres > ressources multimédia spécifiques). > > * Déploiement autoportant : l'objectif est de rendre le plus possible > l'application indépendante du système hôte, de s'approcher d'un > fonctionnement en vase clos. En plus des ressources précédemment > évoquées, le paquet fournit alors l'ensemble des bibliothèques dont > dépend l'application, dans la version prévue par le développeur de > l'application. > > En schématisant un peu, la première approche est l'approche historique > des systèmes Unix, la seconde, est celle de macOS et, dans une moindre > mesure, de MS-Windows. C'est aussi celle des conteneurs plus ou moins > cloisonnés que sont FlatPak, AppImage, Snap et Docker. > > Chacune des approches a des avantages et inconvénients, différents (ou > plus ou moins prégnants) selon qu'on est développeur de l'application, > administrateur du système ou utilisateur de l'application. > > Pour l'administrateur : > > * Le déploiement intégré facilite la maintenance du système et réduit > les ressources requises sur disque et en RAM. En mettant à jour la > bibliothèque lorsqu'un bogue ou une faille de sécurité est identifié, > on patche d'un coup toutes les applications qui l'utilisent. C'est > idéal du point de vue de la sécurité. Une seule copie de la > bibliothèque est stockée sur le disque et une seule copie est chargée > en mémoire. Le déploiement intégré est donc moins couteux en > ressources matérielles, mais les ressources disponibles augmentant > avec le temps, cet argument porte de moins en moins (sauf, sans doute, > dans l'embarqué). Par contre, si l'ABI de la bibliothèque change, > toutes les applications qui l'utilisent doivent être recompilées et un > nouveau paquet doit être publié pour chacune d'entre elles. La > propagation des corrections peut de ce fait être ralentie. > > * Le déploiement autoportant fait que la mise à jour du système est sans > effet sur l'application. Celle-ci, ou plutôt son paquet, doit faire > l'objet d'une mise à jour spécifique. La mise à disposition d'une > nouvelle version d'un paquet dépend de la réactivité des mainteneurs > de l'application. La sécurisation du système est donc progressive. > Pour l'administrateur et du point de vue de la sécurité, c'est un > cauchemar. Ce problème est cependant contrebalancé par le > cloisonnement qu'opèrent les conteneurs. S'il est strict et propre, > l'application n'a qu'un accès limité au système. Les failles de > sécurité dont elle souffre ont donc un pouvoir de nuisance limité. > > Quelle stratégie l'emporte auprès des administrateurs ? Pour l'instant, > aucune, même si on sent bien que le vent change et que le déploiement > autoportant est en train de gagner des adeptes (pas grâce à Snap, > FlatPak ou AppImage, mais grâce aux véritables conteneurs que sont > Docker et consors). > > Pour le développeur : > > * Le déploiement intégré est un fardeau qui lui prend une énergie > considérable et l'empêche de se concentrer sur des fonctions utiles et > des tâches plus motivantes. En effet, le développeur n'est pas libre > d'utiliser la version qui lui plait d'une bibliothèque, mais celle > disponible sur l'environnement cible. Lorsque les environnements > cibles se multiplient, les versions aussi. Et ce n'est pas qu'un > problème de plateforme GNU/Linux ou MS-Windows ou macOS. La version de > la bibliothèque mise à disposition diffère selon la distribution > (Debian, Mint, Alma, Manjaro, OpenSuse…), selon la version de cette > distribution (Debian Bullseye, Bookworm ou Trixie), selon que le > système est mis à jour six fois par jour ou une fois par semestre, > selon qu'il est déployé sur une plateforme Intel ou ARM. L'API, les > fonctions offertes, les performances, les bogues ne sont donc pas les > mêmes d'un environnement à l'autre. Et je ne parle même pas des > options de compilation choisies par les mainteneurs. En outre, une > application dépend en général de plusieurs bibliothèques, au point > qu'il devient « impossible » de trouver un socle commun à tous les > environnements. > > Le développeur doit s'interdire d'utiliser les versions trop récentes > des bibliothèques, dont les fonctions qui lui font de l'œil et > pourraient résoudre efficacement ses problèmes. C'est frustrant. > Lorsqu'un utilisateur lui signale un bogue, le développeur doit > précisément caractériser son environnement, puis réussir à reproduire > cet environnement s'il ne reproduit pas le bogue dans son > environnement de travail habituel. C'est usant. J'ai eu de nombreux > témoignages directs à ce sujet et je connais plus d'un projet qui > a cessé de supporter certains environnements pour réduire la charge > sur les mainteneurs. > > * Il ne faut donc pas s'étonner que de plus en plus de projets décident > de s'émanciper, qu'ils créent dans un conteneur un environnement > parfaitement maitrisé par eux et autoportant, et qu'ils déclarent ne > supporter que les déploiements effectués via ce conteneur (c'est par > exemple le cas de Discourse). Le déploiement autoportant engendre > cependant de nouvelles responsabilités pour les développeurs de > l'application. Puisqu'ils ont créé l'environnement, ils en deviennent > responsables. Il leur incombe d'assurer la veille technologique et > sécuritaire sur les composants qu'ils utilisent, et de fournir dans > les meilleurs délais des versions corrigeant les problèmes. > > Un déploiement qui s'abstrait des contraintes du système, c'est aussi > ce que recherchent les développeurs Python avec leurs « virtual > envs », mais c'est aussi ce qu'apprécient les développeurs Rust et Go. > Et là, on ne parle même pas de Snap ou de Docker. > > Je pense que de plus en plus de développeurs parmi ceux qui veulent que > leur application fonctionne « partout » vont succomber au charme des > déploiements autoportants. > > Pour l'utilisateur : > > * Il est bien souvent administrateur de son propre poste ; ce que j'ai > dit pour l'administrateur vaut en partie pour l'utilisateur. > > * Mais de manière générale, un simple utilisateur est cependant moins > sensible aux questions de sécurité. Son besoin n'est pas d'assurer > l'intégrité d'un système, mais la production d'un document, la > réalisation d'une tâche, au moyen d'un ou plusieurs logiciels. Cet > utilisateur peut être frustré de ne disposer que d'une version > antédiluvienne de son outil préféré dans les dépôts natifs de sa > distribution. S'il apprend qu'une version bien plus récente de l'outil > est disponible dans un dépôt tiers ou via un paquet Snap ou AppImage, > il hésitera rarement à s'approvisionner par ce biais. > > L'utilisateur n'a guère conscience des enjeux et il est seulement > intéressé par la satisfaction de ses besoins, ce qui se comprend (j'ai > moi-même ce comportement dans beaucoup d'autres domaines, par exemple, > avec ma voiture : la seule chose qui m'intéresse est qu'elle fonctionne > et m'emmène à bon port, je prends rendez-vous au garage pour l'entretien > et je paie, le reste, c'est le problème du garagiste, pas le mien). > > Au final, quoi qu'on en pense, je suis persuadé que l'approche > déploiement autoportant / conteneur va finir par l'emporter et qu'un > jour où l'autre, notre système d'exploitation se résumera à un socle > minimaliste faisant tourner peu ou prou tous nos outils dans autant de > conteneurs à la porosité minimale. Il me semble que c'est la voie que > proposent déjà les distributions Ubuntu Core et Zorin OS. > > Sébastien > > > -- > Sébastien Dinot, [email protected] > https://www.palabritudes.net/ > Ne goutez pas au logiciel libre, vous ne pourriez plus vous en passer ! > -- M Pierre Malard « L'émancipation politique doit marcher de pair avec l'émancipation sociale ou les résultats sont désastreux » Romain Gary - "Les racines du ciel" |\ _,,,---,,_ /,`.-'`' -. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
signature.asc
Description: Message signed with OpenPGP
