Journal antistress a t-il eu raison d'installer son Firefox en version Flatpak ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
12
2
juin
2025

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 ?

le penseur de Rodin, photo par marmontel sous licence CC BY 2.0, SOURCE : https://www.flickr.com/photos/marmontel/51071911292/

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  . Évalué à 8 (+7/-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  (site web personnel) . Évalué à 4 (+2/-0).

      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.

      ? pas sûr de comprendre

      • [^] # Re: Beyond Good & Evil

        Posté par  (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  . Évalué à 7 (+5/-0).

          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.

          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  (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  (site web personnel) . Évalué à 5 (+3/-0).

              D’accord mais il est quand même réel.

              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 ?

              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.

              ? 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  . Évalué à 3 (+1/-0).

              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"…

              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  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

                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.

                Hein ?

                “It is seldom that liberty of any kind is lost all at once.” ― David Hume

                • [^] # Re: Beyond Good & Evil

                  Posté par  . É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  . É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  (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

                    Ce qui rend les commandes accessibles à tous les utilisateurs du système c’est

                    • d’abord (et avant tout) qu’elles soient exécutables par toutes et tous (typiquement faire un chmod a+rw ou comparable) ; peut importe qui l’a installé et/ou qui les possèdent alors.
                    • ensuite (éventuellement) qu’elles soient dans le $PATH défini par défaut : si par exemple ton système est configuré avec /home/chezmoi/commun dans lequel j’ai le droit d’écrire sans être root alors je peux y poser des binaires accessibles à tous. Les installations se font avec root parce 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  . Évalué à 3 (+1/-0).

                      si par exemple ton système est configuré avec /home/chezmoi/commun dans lequel j’ai le droit d’écrire sans être root alors je peux y poser des binaires accessibles à tous

                      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  (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  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

        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

        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  . Évalué à 3 (+1/-0).

          Et sinon, il suffit de distribué le logiciel lié en statique avec ses librairies?

          On perd donc tout l'intérêt

          • [^] # Re: Beyond Good & Evil

            Posté par  (site web personnel) . Évalué à 4 (+2/-1).

            Les bibliothèques dynamiques sont utilisées pour plusieurs choses:

            1. réduire l'espace disque/mémoire ;
            2. simplifier les mises à jour ;
            3. proposer des services.

            L'enfer de la mode des 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 :

            • faire une ABI rétrocompatible est difficile ;
            • il n'y a pas de mécanisme de sécurité.

            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  . É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  (site web personnel) . Évalué à 4 (+3/-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  . Évalué à 1 (+2/-2).

      Y'a surtout un repo debian …

      • [^] # Re: Pourquoi ?

        Posté par  (site web personnel) . Évalué à 5 (+3/-0). 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  (site web personnel) . Évalué à 4 (+3/-2). Dernière modification le 03 juin 2025 à 11:43.

      Pourquoi tu l'installes par Flatpak

      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  (site web personnel) . Évalué à 5 (+3/-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  (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  . É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  (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  . É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  (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  . É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 :

            • maven
            • docker
            • firefox
            • gnome
            • emacs
            • thunderbird
            • wine
            • ssh
            • java
            • kde/plasma

            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  (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  (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  . Évalué à 4 (+2/-0).

              Normalement on devrait déjà avoir la conf dans $HOME/.config, mais nombre d'application n'en font qu'a leur tête

              • maven
              • docker
              • firefox
              • gnome [ … ]

              Tous les exemples que tu donnes, sauf sans doute Docker, datent de bien avant la "normalisation" de $HOME/.config par Freedesktop. Et d'ailleurs, d'après le standard, $HOME/.config n'est pas fixe, les fichiers de config sont à mettre dans $XDG_CONFIG_HOME et à défaut dans $HOME/.config.

        • [^] # Re: Ne Suse que si on Sancerre

          Posté par  . É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  . Évalué à 5 (+2/-0). Dernière modification le 03 juin 2025 à 18:37.

            Ça parait pertinent que GIMP (pour ne citer que lui) ait accès au $HOME pour pouvoir lire/écrire des fichiers.

            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

  • # Librewolf

    Posté par  (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

    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

  • # Hein quoi ?

    Posté par  . É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

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.