antistress adventure in Flatpak land est un journal que j'ai rédigé le 30 avril 2024 sur demande, pour raconter mon passage du paquet Firefox de ma distribution (Debian Testing) au paquet Flatpak de Firefox (officiel, du dépôt FlatHub).
Puis voilà t-y pas que, récemment, un Lien pointant vers l'article The future of Flatpak publié sur LWN.net m'alerte : et si ça avait été une grosse connerie ?
En effet, je relève alors particulièrement ce passage de l'article de LWN.net :
One thing that has been a bit of a pain point, Wick said, is that nested sandboxing does not work in Flatpak. For instance, an application cannot use Bubblewrap inside Flatpak. Many applications, such as web browsers, make heavy use of sandboxing.
They really like to put their tabs into their own sandboxes because it turns out that if one of those tabs is running some code that manages to exploit and break out of the process there, at least it's contained and doesn't spread to the rest of the browser.
What Flatpak does instead, currently, is to have a kind of side sandbox that applications can call to and spawn another Flatpak instance that can be restricted even further. ""So, in that sense, that is a solution to the problem, but it is also kind of fragile"." There have been issues with this approach for quite a while, he said, but no one knows quite how to solve them.
À quoi Sébastien Wilmet répond sous le Lien :
Je trouve ta question intéressante. Mais pour avoir une réponse précise j'ai l'impression que le meilleur endroit est encore à la source, sur LWN où les développeurs cités dans l'article répondent (parfois).
Mon commentaire : Is a web browser less secure when run within a Flatpak?
Donc, merci pour cette question :-) Espérons que quelqu'un sur LWN y réponde.
Depuis, une réponse a été postée :
I was wondering the same thing while reading the article. Comparing the Sandbox section of about:support between the Flatpak and native Fedora versions, the only difference is that "User Namespaces" is false with Flatpak. Everything else is the same, including the "Sandbox Level" values.
Chez OSnews on peut également ce commentaire d'un lecteur :
Flatpak sandboxing very badly breaks browser internal sandboxing, to a point that I don’t think an up to date Firefox or Chromium based browser running in Flatpak can be called adequately secure. Zypak helps with Chromium based browsers to a point, but the real issue is that breaking namespaces gets rid of a lot of horizontal sandboxing between tabs. What’s more, it looks like this could all be avoided by providing a way to bypass Flatpak sandboxing, as is possible in Snaps… Or by using a normal MAC framework for the external sandbox, again as in Snaps. But those are not things that will happen if Flatpak is in maintenance mode.
Alors : antistress a t-il eu raison d'installer son Firefox en version Flatpak ?
On dirait bien que c'était une connerie. Qu'en pensez-vous ?
# Beyond Good & Evil
Posté par AlexTérieur . Évalué à 9 (+8/-0). Dernière modification le 02 juin 2025 à 22:43.
Haha, j'aime bien ta petite série :)
On en revient toujours au même point : est-ce vraiment une bonne idée l'"empaquetage" (façon flatpak ou autre) sous Linux…
Sachant que je suis sous Fedora…
Je suis vachement alléché par l'offre logiciels sous Gnome Software sans passer par les fameux RPM… mais quand tu vois qu'un logiciel qui fait "3 fois rien" mais qui te permet certaines choses, donc tu te dis qu'il pèsera rien même sous flatpak, et que plus loin on te met "nécessite 465 Mo d'espace supplémentaire"… tu te poses sincèrement des questions. Pas seulement consommation mémoire stockage, mais aussi, est-ce avec tout cet espace nécessaire aussi sécurisé que dit… Bah… le doute est permis.
[^] # Re: Beyond Good & Evil
Posté par saltimbanque (site web personnel) . Évalué à 4 (+2/-0).
? pas sûr de comprendre
[^] # Re: Beyond Good & Evil
Posté par abriotde (site web personnel, Mastodon) . Évalué à 3 (+3/-1).
Bah en gros, selon le principe que "plus on en rajoute, plus on en rajoute de la surface d’attaque", flatpack réduit la sécurité alors qu’il prétends le contraire.
Je pense que de base c’est exagéré de conclure ça car flatpack, par l’isolation Docker, rajoute bien une sécurité pour l’OS.
Par contre ce que ce problème révèle, c’est que comme le soft n’à pas été conçu pour flatpack il peut y avoir des effets de bord qui nuisent à la sécurité interne du logiciel.
Dis autrement tu ne peux pas pourrir Linux (sauf à exploiter une faille docker en plus) mais pourrir les autres onglets…
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beyond Good & Evil
Posté par Voltairine . Évalué à 8 (+6/-0).
Attention, Flatpak et Docker sont des choses bien différentes :
https://flatpak.org/faq/#Is_Flatpak_a_container_technology_
https://stackshare.io/stackups/docker-vs-flatpak
Quant à l'isolation du reste du système elle est forcément partielle et attention au faux sentiment de sécurité. Avoir une application qui embarque des bibliothèques avec des failles (car non mises à jour), qui n'est ni contrôlée, ni corrigée par les mainteneurs d'une distribution n'est peut-être pas la meilleure des pratiques en terme de sécurité.
[^] # Re: Beyond Good & Evil
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+2/-1).
D’accord mais il est quand même réel. Avant il faut dire que que l’application avait pratiquement tous les droits… y compris celle téléchargé sur le Web que t’installe en root. "sudo apt add && sudo apt install"…
Le problème c’est qu’effectivement comme les mainteneurs ne font plus pression sur les devs pour mettre à jour l’application le risque est plus important qu’un laxisme s’installe. Avant si ton application dépendait de lib trop ancienne elle pouvait être supprimé des repo officiels et donc perdre en visibilité.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beyond Good & Evil
Posté par BAud (site web personnel) . Évalué à 5 (+3/-0).
c'est pas parce que ça pouvait être pire avant que c'est mieux après ;-) pour reprendre l'exemple du navigateur, pourquoi ne pas se contenter du paquet emmbarqué par la distribution ? le web ne change pas si vite que cela, autant attendre que l'application soit correctement empaqueté et intégrée ?
? c'est plutôt le contraire : les dév mettent à jour et ça prend du temps à être pris en compte dans la distribution… quand c'est dans une bibliothèque, ça interagit avec les autres applications l'utilisant, surtout s'il y a une rupture d'API… sinon, bah c'est transparent, même pas besoin de recompiler l'application pour une mise à jour de sécurité de bibliothèque.
[^] # Re: Beyond Good & Evil
Posté par Voltairine . Évalué à 3 (+1/-0).
Je ne comprends pas ton argumentaire.
Une application a les droits de l'utilisateur sous lequel elle s'exécute. Dans le cas de ce journal il s'agit du navigateur web qui s'exécute avec les droits de l'utilisateur antistress.
L'installation d'une application accessible à tous les utilisateurs du système nécessite de toute façon les droits root, peu importe le mode de distribution.
Une application téléchargée sur le Web sous forme de paquet Debian sans précautions, c'est aussi sécurisé que d'installer un exe sous Windows, un flatpak ou autre. Si l'application est vérolée (mineur de crypto par exemple) le mode de distribution n'y changera rien. Le seul intérêt de l'exécution dans un bac à sable est de rendre plus difficile la prise de contrôle totale du système.
[^] # Re: Beyond Good & Evil
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+0/-0).
Hein ?
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beyond Good & Evil
Posté par Voltairine . Évalué à 3 (+1/-0).
Peux-tu développer ?
Quelle technique utilises-tu pour installer, sans être root, une application qui soit accessible à tous les utilisateurs du système ?
[^] # Re: Beyond Good & Evil
Posté par vahgeo . Évalué à 0 (+0/-0).
En fait j'ai aussi mal compris au debut :
Pour etre clair, une application accessible a tout les utilisateurs, ne necessite pas d'etre root pour l'utiliser, a partir du moment ou l'application a le droit d'execution pour l'utilisateur, tout est ok (bon je simplifie un peu cette derniere partie)
Ce qui demande d'etre root, et une unique fois, c'est pour l'etape d'installation, apres tu n'as plus besoin de droit d'access a la root(s) pour utiliser l'application
[^] # Re: Beyond Good & Evil
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4 (+2/-0).
Ce qui rend les commandes accessibles à tous les utilisateurs du système c’est
chmod a+rwou comparable) ; peut importe qui l’a installé et/ou qui les possèdent alors.$PATHdéfini par défaut : si par exemple ton système est configuré avec/home/chezmoi/commundans lequel j’ai le droit d’écrire sans êtrerootalors je peux y poser des binaires accessibles à tous. Les installations se font avecrootparce que c’est le compte qui a le droit d’écrire dans/bin,/sbin/,/usr/local/,/etc/, etc.À noter que la plupart des gestionnaires de paquet permettent de faire une installation dans une arborescence autre que la racine et en tant que simple utilisateur ou utilisatrice.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beyond Good & Evil
Posté par Voltairine . Évalué à 4 (+2/-0).
Un système correctement configuré ne permet pas aux utilisateurs de lire le contenu du répertoire personnel des autres. Pas mal de distribution définissent HOME_MODE à 750, ce qui signifie que /home/toto n'est cessible qu'à toto.
Oui évidemment on peut faire cela. Mais installer un binaire accessible à tous dans un répertoire personnel n'est pas conforme au standard FHS et surtout présente des risques de sécurité.
Petite parenthèse un fichier n'a pas besoin d'être exécutable ; le bit d'exécution +x n'est là que pour rendre la chose facile. Il ajuste besoin d'être accessible en lecture et d'être appelé avec son interpréteur (du type ld-linux-****.so pour les binaires ELF).
[^] # Re: Beyond Good & Evil
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Tu suppose, parce-que tu vois « home » que c’est un répertoire personnel et fais semblant de ne pas voir « commun » :) Il n’est pas obligatoire que ton toto ait pour répertoire /home/toto (sinon il n’y aurait pas de raison de prévoir ce champ dans le
/etc/passwdn’est-ce pas ?) Mais tu peux remplacer mon exemple par/opt/foosi ça t’aide à comprendre le point (être dans le chemin recherché, et que FHS n’est pas un dogme indépassable) :)En attendant, on va partir à la chasse à toutes ces solutions qui permettent d’exposer les répertoires personnels (e.g. Apache UserDir)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Beyond Good & Evil
Posté par Voltairine . Évalué à 3 (+1/-0).
Sauf que /home comme /opt ne sont accessibles en écriture qu'à root, on tourne en rond. :-D
Évidemment tu peux bidouiller les droits d'accès, le groupes et les utilisateurs pour arriver à ce que tu dis mais c'est au mépris des bons usages et de la sécurité (qui était la préoccupation initiale du journal)
L'utilisation de ce module d'Apache est reconnue pour être un problème de sécurité et pas seulement pour les raisons indiquées dans la doc officielle.
[^] # Re: Beyond Good & Evil
Posté par fearan . Évalué à 3 (+1/-1).
Non a toto et aux membres du groupe du dossier toto. Pour n'être accessible qu'à toto il faut faire un 700 :) 750 donne un accès en lecture et traversé sur le dossier aux membres du groupe. :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Beyond Good & Evil
Posté par abriotde (site web personnel, Mastodon) . Évalué à 0 (+2/-3).
Non :
* Tout d'abord une application sous forme de paquet debian, tu l'installe en faisant un "sudo apt install", elle a donc les droits root, elle peut donc installer une backdoor en root et faire ce qu'elle veut. Elle a donc potentiellement plus de droits que ton simple user. Et heureusement pour quand tu installe un serveur ou un pare-feu.
* Ensuite, une application flatpack, c'est un peu comme un docker, elle tourne dans un environnement isolé. Elle n'a accès qu'aux répertoires ou on lui a donné accès. Alors, oui, elle peut tourner h24 et servir un botnet… mais elle ne peut pas accéder à tes données personnelles… du moins sans une autorisation. En fait en pratique les droits flatpack ne sont pas hyper développés mais on peut en théorie faire comme sur Androïd. Il n'empèche que si tu télécharge sur internet une application flatpack tu risque moins qu'un paquet debian.
* Un exe Windows, c'est comme un paquet debian… sauf qu'en plus il embarque toutes ses lib et donc plus souvent des lib obsolètes avec des failles. C'est donc le pire du paquet debian avec le pire du flatpack.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beyond Good & Evil
Posté par Benoît Sibaud (site web personnel) . Évalué à 6 (+3/-0). Dernière modification le 05 juin 2025 à 16:43.
à celui qui a empaqueté en tout cas:
Après si toi tu lances /usr/bin/une_app en root ou avec sudo, tu donnes indirectement les droits à upstream aussi.
[^] # Re: Beyond Good & Evil
Posté par Luc-Skywalker . Évalué à 3 (+1/-0).
Tu pourrais développer ce que ça veut dire en pratique ?
"Si tous les cons volaient, il ferait nuit" F. Dard
[^] # Re: Beyond Good & Evil
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+2/-1).
Clairement flatpack (ou autre) c’est une solution de simplicité pour le mainteneur mais aussi pour les devis…
C’est avant tout une solution aux problèmes de compatibilité des dépendance qui peuvent être un enfer. Un enfer qui cause souvent des problèmes à l’utilisateur final quand il se retrouve avec des bugs à cause d’une utilisation non conventionnelle.
* En Python, les problèmes liés aux dependaces avec pip qui ont poussé les distributions a virer pip… pour forcer les venv.
* Les problèmes plus généraux de versions de dépendances ( lib) différentes. Il était courant d’avoir un problème parceque un logiciel réclame lib1 et que tu n’a que lib1.3.2 mais qu’en fait ça marche que jusqu’a lib1.2.9… il faut compiler lib1.2 et faire le lien.
C’est aussi un atout sécurité. Même si le logiciel est compromis (par les sources ou par une faille) il ne devrait pas corrompre l’OS.
Alors oui, chaque solution à ses avantages et inconvénients. Celle-ci est sa consommation de ressources à tous les niveaux.
Je crois qu’il y a un compromis à trouver : les logiciels par défaut et bien maintenus (bien vérifier comme firefox) ne devraient pas être en flatpack selon moi.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beyond Good & Evil
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Courant chez qui? J'ai très rarement vu ce type de problème en installant des paquets Debian (les packagers de la distribution font bien leur travail) ou même en compilant des applications pour mon système (qui utiliseront alors les bibliothèques disponibles).
Et sinon, il suffit de distribué le logiciel lié en statique avec ses librairies?
[^] # Re: Beyond Good & Evil
Posté par ff9097 . Évalué à 2 (+1/-1).
On perd donc tout l'intérêt
[^] # Re: Beyond Good & Evil
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+2/-1).
Les bibliothèques dynamiques sont utilisées pour plusieurs choses:
L'enfer
de la modedes dlls relativise l'intérêt des deux premiers.Pour le dernier, on préfère aujourd'hui proposer via un mécanisme d'IPC (socket, dbus, webservice…), car avec les bibliothèques dynamiques :
Peut être qu'il faut abandonner le concept de bibliothèques dynamiques ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Beyond Good & Evil
Posté par abriotde (site web personnel, Mastodon) . Évalué à 2 (+1/-0).
Oui mais pas assez. Ils manquent de temps/argent :
Les paquet debian empaquettent souvent les anciennes versions des logiciels. A cela plusieurs raisons:
La nouvelle version du logiciel utilise une librairie qui n'est pas dans les paquets debian. Mais si on met a jour la librairie, on casserait un autre logiciel qui lui n'est pas capable d'utiliser la nouvelle version de la librairie. (On peut patcher avec plusieurs version de la librairie mais c'est casse gueule)
Les packagers manquent de temps pour tester la dernière version du logiciel avec ses dépendances dans notre environnement.
Et si c'est relativement courant d'avoir des incompatibilité. Alors aujourd'hui elles sont parfois détectés par le "apt install" qui te donne un message "Impossible d'installer le logiciel car il a besoin de tel truc.1.3". Le truc est installer mais pas à la bonne version. Il faut alors désinstaller un autre logiciel pour pouvoir installer le logiciel voulu.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: Beyond Good & Evil
Posté par AlexTérieur . Évalué à 1 (+0/-0). Dernière modification le 03 juin 2025 à 19:13.
Alors je me réponds à moi-même.
Car il y a d'autres problèmes que je n'ai pas évoqué.
Il y a aussi les logiciels qui doivent accéder à des parties spécifiques de ton /home/, sauf si tu t'amuses à copier les fichiers concernés dans la config de l'appli dans $HOME/.var/app/… donc à au moins chaque mise à jour, tu dois reconfigurer lesdit logiciels…
# Pourquoi ?
Posté par Tarnyko (site web personnel) . Évalué à 6 (+5/-1). Dernière modification le 03 juin 2025 à 09:13.
Pourquoi tu l'installes par Flatpak alors que :
- il y a un binaire officiel du projet ;
- sauf erreur, ce binaire officiel fournit son propre système de mise à jour automatique ;
- les navigateurs sont très impactés, en termes de performances et sécurité, par des systèmes de sandboxing "autres" ?
[^] # Re: Pourquoi ?
Posté par oau . Évalué à 1 (+2/-2).
Y'a surtout un repo debian …
[^] # Re: Pourquoi ?
Posté par lejocelyn (site web personnel) . Évalué à 4 (+3/-1). Dernière modification le 03 juin 2025 à 10:32.
Y'a surtout un flatpat/snap/appimage…
Bon sérieusement, la discussion est sur l'intérêt d'utiliser Flatpak, donc l'idée serait d'argumenter sur le pourquoi on préfèrerait une source à une autre. Par exemple parce que l'on souhaite utiliser le paquet qui suit la politique de sa distribution (et les choix qui y sont associés), soit utiliser le flatpak qui suit la politique de, bon là, je ne suis pas au clair à ce niveau / pour les fonctionalités que potentiellement flatpak possède (et que l'on discute ici).
[^] # Re: Pourquoi ?
Posté par antistress (site web personnel) . Évalué à 5 (+5/-3). Dernière modification le 03 juin 2025 à 11:43.
Parce que le bac à sable apporte normalement une sécurité, et que le navigateur est justement un vecteur d'attaque privilégié.
Sauf qu'au cas d'espèce…
[^] # Re: Pourquoi ?
Posté par Tarnyko (site web personnel) . Évalué à 9 (+7/-0). Dernière modification le 04 juin 2025 à 04:43.
….Mouais 😉.
'tation hein, j'ai bien compris que ton but était de faire de "point" sur l'usage de Flatpak (et peut-être des stores en général) !
Mais c'est juste que là, avec un navigateur (à savoir, sans doute l'application la plus complexe qui tourne sur ton OS -juste moins complexe que l'OS lui-même !), on tient facilement le pire exemple.
On utilisait au départ plutôt Flatpak, Snap… pour les applis non-packagées sur sa distro.
Chaque navigateur a plusieurs binaires officiels ET un paquet de distro ;
On évitait de les utiliser pour des applis trop intensives, à cause du ralentissement lié à la sandbox.
A part un jeu vidéo 3D, le navigateur est l'appli la plus intensive qui soit ! Il héberge lui-même des moteurs d'exécution 3D, VR, JavaScript, WASM… on peut aujourd'hui faire tourner Linux dans QEMU dans un navigateur ;
Eventuellement oui, on peut viser la sécurité par sandboxing… sauf qu'ici :
Chaque navigateur a sa technologie très avancée de sandbox par thread/onglet, qui fait partie de sa "patte". Je connais bien celle de Chrome-ium, moins celle de Firefox; mais c'est du sérieux, l'état de l'art pour déjouer les CVEs connus et à venir.
Bref, bref… j'interviendrai pas beaucoup plus sur le sujet. Sauf pour dire que je préfère la simplicité des .AppImage 😉.
# Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Je ne sais pas ce que vaut la sandbox de Flatpak, mais sur les paquets de logiciels que j'utilise régulièrement, tout est en Potentially Unsafe.
https://flathub.org/apps/org.mozilla.firefox
https://flathub.org/apps/org.gimp.GIMP
https://flathub.org/apps/com.github.libresprite.LibreSprite
https://flathub.org/apps/org.libretro.RetroArch
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par ff9097 . Évalué à 2 (+0/-0).
C'est juste que des droits par défaut ont été accordés pour lire/écrire dans $HOME
[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Donc juste accéder à tous mes secrets et données de valeur :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par ff9097 . Évalué à 3 (+1/-0).
Tu peux révoquer l'autorisation, contrairement à tous ce qui n'est pas sandboxé où c'est open-bar
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 3 (+0/-0).
super ça l'empêche de devenir root pour pirater les données de tous les utilisateurs; à la place ça permet de pirater l'unique utilisateur : moi \o/
c'est si compliqué que ça que de le bloquer a $HOME/applications/nomApplication
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1). Dernière modification le 03 juin 2025 à 14:32.
/home/$appli ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 3 (+0/-0).
non car ça doit rester personnel si 15 personnes utilisent l'application t'as pas forcément envie qu'elles aient leur données en commun.
$HOME/$appli tout court va encombrer le home encore plus.
Normalement on devrait déjà avoir la conf dans $HOME/.config, mais nombre d'application n'en font qu'a leur tête :
note bien certains le font a moitié (gnome et kde sont présent dans le home et le ~/.config )
Par ailleurs tu voudras pouvoir donner des truc locaux a manger à l'application, aller écrire ailleurs que dans $HOME me semble pas une pratique à encourager.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+0/-0).
Pour les jeux (les seules applis privatrices que j'utilise), je crée un utilisateur "jeux".
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
Personnellement, depuis une mésaventure, je créé des comptes spécifiques pour les utilisations risquées (par exemple le développement à base de distribution pas très contrôlée de bibliothèques ; ou bien le compte invité de ma machine). Et je créé aussi des comptes spécifiques pour les choses sensibles (clés ssh d'administration système par exemple). En prenant soi de vérifier que la lecture est bien cloisonnée entre comptes.
Adhérer à l'April, ça vous tente ?
[^] # Re: Ne Suse que si on Sancerre
Posté par aiolos . Évalué à 4 (+2/-0).
Tous les exemples que tu donnes, sauf sans doute Docker, datent de bien avant la "normalisation" de
$HOME/.configpar Freedesktop. Et d'ailleurs, d'après le standard,$HOME/.confign'est pas fixe, les fichiers de config sont à mettre dans$XDG_CONFIG_HOMEet à défaut dans$HOME/.config.[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 4 (+1/-0).
Bien sûr, mais pourquoi ils refusent d'implémenter ce standard ?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par Pierre-Alain TORET (Mastodon) . Évalué à 3 (+2/-0).
Pour SSH les réponses sont dans le ticket https://bugzilla.mindrot.org/show_bug.cgi?id=2050 mais qui n'est plus en accès libre.
Les raisons sont les suivantes :
Trouvé via cette discussion superuser
[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 5 (+2/-0). Dernière modification le 04 juin 2025 à 13:24.
L'argument de la tendance me semble démodé :-)
Aujourd'hui XDG_CONFIG_HOME a plus de 20 ans: la trace la plus ancienne que je trouve date de 2003.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 5 (+2/-0).
foutage de gueule : recherche dans .config/ssh* puis si rien .ssh/ ça permet de garder la configuration ascendante, et si tu crains que des gens vont rater l'évol tu fais un check si c'est présent a 2 endroits et tu demande à l'utilisateur de nettoyer sa conf, un peu comme quand y'a une machine en face qui a bougé.
* ou pour être plus précis "${XDG_CONFIG_HOME:-$HOME/.config}/ssh" ou "$HOME/.ssh"
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Ne Suse que si on Sancerre
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2 (+2/-2).
Je t’en pris, soumets ton patch et engage toi à le maintenir !
Et sinon, y a pas que ce foutu OpenSSH hein…
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 3 (+0/-0).
depuis kde est passé à kde4, puis plasma, gnome a aussi changé de version majeure, firefox à changé son mode de versionnage, et dans le temps il était rangé dans .mozilla
Bref de l'eau a coulé sous les ponts.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Ne Suse que si on Sancerre
Posté par ff9097 . Évalué à 2 (+0/-0).
Ça parait pertinent que GIMP (pour ne citer que lui) ait accès au $HOME pour pouvoir lire/écrire des fichiers. Après tu peux ouvrir un ticket pour savoir pourquoi les droits sont accordés par défaut
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 5 (+2/-0). Dernière modification le 03 juin 2025 à 18:37.
non $HOME/Images, il n'a rien a faire de mon profile firefox par exemple.
ou si tu veux être plus large $HOME/* (ce qui va de facto exclure tout ce qui commence par .)
mais $HOME en général c'est aussi $HOME/.ssh/id*, .profile, .bashrc…
et donc à supposer qu'il y'ait une faille dans une ouverture d'image, tu laisse GIMP expédier tes clés ssh dans le web, ou modifier ton .bashrc ou…
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Ne Suse que si on Sancerre
Posté par ff9097 . Évalué à 2 (+0/-0).
Bah ouvre un ticket GIMP pour changer ça
[^] # Re: Ne Suse que si on Sancerre
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 04 juin 2025 à 14:50.
Et pour Firefox c'est ici https://bugzilla.mozilla.org/show_bug.cgi?id=259356
À l'époque, si ma mémoire est bonne, Jean-François Fortin Tam et, je crois Ploum, et moi-même avions spammé les bug trackers pour réclamer la conformité avec le standard de nos applis
Charles Aznavour chantant La bohème.
[^] # Re: Ne Suse que si on Sancerre
Posté par devnewton 🍺 (site web personnel) . Évalué à 3 (+1/-1).
Ça montre une chose : même avec du logiciel libre développé par des fondations/associations/…, les utilisateurs ne peuvent pas avoir confiance dans leurs applications.
Il manque effectivement une grosse couche de sandboxing dans linux, mais pas sur le modèle "les applis demandent des permissions" (vu qu'elles vont toujours en demander trop).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Ne Suse que si on Sancerre
Posté par pas_pey . Évalué à 1 (+0/-0).
Sinon en encore plus radical il y a https://www.qubes-os.org/
[^] # Re: Ne Suse que si on Sancerre
Posté par fearan . Évalué à 7 (+4/-0).
Gimp ne correspond pas aux besoins que j'ai en modification d'image; et même dans ce cas j'utiliserai celui intégré a la distrib qui lui a accès à la totalité du système.
Je réagissais juste au fait qu'on pense qu'avoir accès a tout $HOME est normal; et cela ne me semble pas le cas; si on met une restriction, autant qu'elle soit utile; ce qui est important sur mon système c'est pas /usr/ /etc/ /lib ou /bin; je peux reprendre une image d'installe et tout remettre en marche, ça prendra 2H ou plus, mais ça reste un temps raisonnable.
La perte de mon $HOME; ou pire, la divulgation des données confidentielle ce celui ci me sont bien plus dommageable.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Librewolf
Posté par ploum (site web personnel, Mastodon) . Évalué à 4 (+5/-3).
Perso, les snap et flatpak m’ont beaucoup ennuyé à l’époque où ça rendait l’utilisation de la carte d’identité électronique belge impossible.
https://ploum.net/2022-04-05-firefox-ubuntu.html
Depuis, je préfère rester sur le paquet de la distro. Et, dernièrement, je suis passé à Librewolf via extrepo sous Debian. Je recommande chaudement car Librewolf me semble, par défaut, bien plus sécurisé que Firefox.
https://linuxfr.org/users/ploum/journaux/librewolf-ce-que-firefox-devrait-etre
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Librewolf
Posté par Sylvestre Ledru (site web personnel) . Évalué à 10 (+13/-1).
[je travaille sur Firefox]
Si je peux me permettre, « semble […] bien plus sécurisé » est une impression probablement incorrecte. À ma connaissance / d’après ce que j’ai pu voir, LibreWolf n’ajoute pas de développement spécifique en matière de sécurité par-dessus Firefox.
Il se contente probablement d’activer certaines préférences introduites par les contributeurs/développeurs de Firefox (ou de l’équipe Tor). Si ces options ne sont pas activées par défaut dans Firefox, c’est qu’il y a de bonnes raisons à cela : impact sur les performances, régressions de compatibilité web, sites cassés, amélioration de la sécurité limitée, etc.
# Hein quoi ?
Posté par Luc-Skywalker . Évalué à 4 (+2/-0).
Je veux bien donner mon avis, mais il est ou le sondage ?
"Si tous les cons volaient, il ferait nuit" F. Dard
# un choix, plus qu'une solution universelle?
Posté par crocodile_13 (Mastodon) . Évalué à 3 (+3/-0). Dernière modification le 07 juin 2025 à 13:14.
J'arrive un peu à la bourre, sujet très intéressant que je ne connaissais pas !
Je suis sur Arch, par commodité j'utilise beaucoup Flatpak… flute alors, la boulette ?
De ce que je comprends (pour Firefox × Flatpak), en terme de sécurité uniquement :
=> Firefox via Flatpak : isolation de Firefox en un bloc, meilleure isolation vis-à-vis du système hôte, mais ça détruit complètement l'isolation inter-processus (inter-onglets donc) de Firefox, contrairement à Chromium qui, semblerait-il, a un mécanisme de contournement. Patch un peu retardé.
=> Firefox via pacman ou autre : on bénéficie de l'isolation inter-processus de Firefox, par contre Firefox a un accès beaucoup plus large aux ressources… Par contre on a des patch quasi instantanés (dautant plus que je suis en rolling realeases)
Si c'est bien ça, ce sont deux options différentes…
Exemple fictif :
=> J'ai confiance en Mozilla, donc en firefox lui meme, donc j’installe via pacman.
=> Imaginons un super navigateur que j'adore, mais de conception chinoise assez obscure, j'ai peut-être moins confiance en le logiciel lui-même, donc je préfère l'isoler, mais en contre partie, plus exposer mes données de navigation côté web ?
Bon de mon coté je vais decaler de flatpak à une install classique pour mon firefox!
._.
# Ayé
Posté par antistress (site web personnel) . Évalué à 4 (+1/-0).
Ayé, j'ai rebasculé sur le paquet deb de ma distrib !
Vais faire la même chose pour Thunderbird.
[^] # Re: Ayé
Posté par Sylvestre Ledru (site web personnel) . Évalué à 4 (+2/-0).
Tu as aussi:
https://support.mozilla.org/fr/kb/installer-firefox-linux#w_installation-par-paquet-deb-pour-les-distributions-basees-sur-debian-recommande
Et ça arrive pour tb:
https://bugzilla.mozilla.org/show_bug.cgi?id=1893603
[^] # Re: Ayé
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 11 juin 2025 à 15:12.
Oui, c'est ce que j'ai suivi pour Firefox.
Et j'ai vu qu'il n'y avait pas encore d'équivalent pour Thunderbird, donc je suis en ESR avec ce dernier ;)
Poste un lien quand ça sort !
[^] # Re: Ayé
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 11 juin 2025 à 22:52.
Pour info, récupérer mes profils de Flatpak Firefox 134.0.1 [1] dans Mozilla deb Firefox 139.0.3 n'a pas été simple : certains profils ne s'ouvraient pas (trois sur cinq) et j'ai dû utiliser l'argument
-allow-downgradeet parfois faire plusieurs tentatives ainsi pour réussir à tous les récupérer…[1] mon SSD est quasi plein j'ai dû faire des compromis d'espace / MàJ ces derniers mois faute de temps pour installer le nouveau
[^] # Re: Ayé
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2 (+0/-0).
Pour ça, je peux pas t'aider :)
[^] # Re: Ayé
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0).
En tout cas ça c'est réglé avec cet argument bien pratique pour le coup !
A+
antistress
[^] # Re: Ayé
Posté par antistress (site web personnel) . Évalué à 3 (+0/-0).
Ha oui j'ai compris, j'ai été un peu vite en écrivant
puisque c'est le paquet du dépôt Mozilla APT que j'ai installé en fait ! :)
[^] # Re: Ayé
Posté par Sylvestre Ledru (site web personnel) . Évalué à 2 (+0/-0).
Cool, par contre, là, je peux aider :p
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.