Cheval de troie dans OpenSSH

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
1
août
2002
Pirate
D'après un mail sur la liste de freebsd-security, le tarball de la dernier version d'openssh portable (openssh-3.4-p1) contient un shell code dans openbsd-compat/bf-test.c, qui sera lancé via Makefile.in si on fait un make.

Vous pouvez comparez avec un miroir :

ftp.openbsd.org (infecté) :
ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz

ftp.lip6.org (non infecté):
ftp://ftp.lip6.fr/pub/OpenBSD/OpenSSH/portable/openssh-3.4p1.tar.gz

Aller plus loin

  • # de mieux en mieux

    Posté par  . Évalué à -4.

    apres les trous de secu c'est les trojans..
    pour un logiciel qui contient secure dans le nom c'est tres fort ...

    -1 mais bon ca commence a souler a la fin !!!

    • [^] # Re: de mieux en mieux

      Posté par  . Évalué à 10.

      ftp.openbsd.org (là où est hébergé le paquet compromis en question) est sur un sunsite, donc sous solaris.

      Ce n'est pas la faute d'OpenSSH (à priori) si le paquet a été compromis mais bien celle de la plateforme d'hébergement.

    • [^] # Re: de mieux en mieux

      Posté par  (site web personnel) . Évalué à 10.

      Moi la question que je me pose (et je dois pas être le seul !) est « mais comment le monsieur a-t-il pu h4x0riser ftp.openbsd.org » ? Est-ce là l'œuvre d'une brébis galeuse chez OpenBSD (peu vraisemblable) ? Y a-t-il une nouvelle faille non découverte dans OBSD ? Ou tout simplement l'admin du site a-t-il raté un épisode ? AMHA cette dernière hypothèse (l'erreur humaine) est encore la plus probable...

      Petit corollaire : si vous compilez des softs -- tout spécialement des softs « sensibles » -- vérifiez *toujours* les checksums. Toujours. Ça commence à devenir une question de vie ou de mort...

      Envoyé depuis mon PDP 11/70

      • [^] # Re: de mieux en mieux

        Posté par  . Évalué à 10.

        Comme je le dis environ 40 pixels au dessus de ton commentaire, {www,ftp}.openbsd.org ne sont pas sous OpenBSD. C'est un SUNsite, une plate-forme d'hébergement de sun, qui fournit de l'espace gracieusement pour faire sa propre pub.
        Si crack de machine il y a eu, c'est de machines Solaris, pas OpenBSD.

        • [^] # Re: de mieux en mieux

          Posté par  (site web personnel) . Évalué à 10.

          Oui, en fait j'ai commencé à écrire le commentaire avant que tu n'envoies le tien et finalement je l'ai validé après, du coup je n'avais pas vu. Ce qui ne m'excuse bien sûr pas, j'aurais dû faire un tour chez Netcraft avant d'ouvrir ma gueule. J'ai juste présumé que, comme la plupart des vendeurs d'OS, OpenBSD ferait tourner ses serveurs avec l'OS qu'ils développent pour faire une sorte de vitrine (c'est le cas de NetBSD et FreeBSD). Donc désolé pour la confusion, ce n'était pas voulu...

          Envoyé depuis mon PDP 11/70

          • [^] # Re: de mieux en mieux

            Posté par  . Évalué à -2.

            Il faut toujours tourner 7 fois ta souris autour de ton PC avant de poster un commentaire. Si tu utilise un navigateur en mode texte, tourne ton clavier 7 fois autour du PC :)


            -1, c'est vraiment n'importe quoi :)

            • [^] # Re: de mieux en mieux

              Posté par  . Évalué à -1.

              surtout qu'il n'y a pas assez de câble pour faire 7 tours de pc avec un clavier ou une souris :)
              ou alors il faudrait faire un nombre pair de tours : la moitié dans un sens, l'autre moitié dans le sens inverse. On peut même répéter l'opération plusieurs fois, le mieux étant de faire 4 fois 2 tours ou 2 fois 4 tours pour les personnes ayant des long câbles.

              Bien entendu, pour les personnes possédant des souris et claviers sans fil, la question ne se pose pas, et il est alors même possible de faire pivoter le périphérique sur lui même, ou autres, les possibilités étant innombrables.

  • # En regardant de plus prés

    Posté par  . Évalué à 10.

    C'est marrant dans ce shell code
    on retrouve une IP
    203.62.158.32
    et un port 6667

    Il y a meme un site internet de
    http://203.62.158.32(...)

    un petit resolv donne :
    snsonline.net

  • # Panique

    Posté par  . Évalué à -4.

    Arghh!!
    Panique a bord...
    Comment qu'ils ont fait les enfoirés, ils ont reussi a percer le ftp de openssh.org pour foutre leur trojan? moi j'ai verifié quelques machines et jusque la pas de problemes mais j'ai pas les checkssums pour les fichiers openssh-3.4.tgz . Mon checksum pour ce fichier est 39659226ff5b0d16d0290b21f67c46f2. Dites moi que c'est bon....

    • [^] # Re: Panique

      Posté par  . Évalué à -3.

      facile ls ont du exploiter une faille de openssh ou de openssl :)

      -1 et [jesors]

    • [^] # Re: Panique

      Posté par  . Évalué à 10.

      D'apres FreeBSD, oui:

      1008 [13:24] root@roadrunner:security/openssh> less distinfo
      MD5 (openssh-3.4.tgz) = 39659226ff5b0d16d0290b21f67c46f2
      MD5 (openbsd28_3.4.patch) = 46cfc2332b357e338e421dd456435a65

      Cela dit, quel est le "bon" checksum sur une machine qui est peut etre compromise depuis des mois ?

      D'autre part les openssh-3.4.tgz ont été deja supprimés des serveurs mais pas les version -portables.

      Bref ...

    • [^] # Re: Panique

      Posté par  (site web personnel) . Évalué à 10.

      C'est pas ce fichier qui est infecté il semble, c'est le openssh-3.4p1.tar.gz
      Le md5 correct est :
      459c1d0262e939d6432f193c7a4ba8a8
      D'après le fichier du lip6 et le mien (ouf :)

  • # et les checksums c pour les chiens??

    Posté par  . Évalué à 10.

    Petite précision pour les décideurs préssé qui n'ont pas le temps d'aller voir les liens : apparement, y'a pas juste la version portable qui était vérolée. La version normal était pareil.

    Enfin bon quand même la signature était plus vielle d'un mois. ça met la puce a l'oreille.
    Moralité: les signatures elles sont pas là que pour faire joli.

    Question subsidiare : combien de personnes vérifient les signatures avant d'installler un softs???

    • [^] # Re: et les checksums c pour les chiens??

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      D'ou la nécessité d'avoir des packets signés, et de vérifier cette signature GPG au moment de l'installation, de manière automatique, comme Debian...

      • [^] # Re: et les checksums c pour les chiens??

        Posté par  . Évalué à 10.

        mais quel est donc cet odeur...ah mais oui c'est bien un gros troll tous poilu!!

        Ceci dis, je ne suis pas sur que le tous automatique soit forcément une bonne idée. Si ça se fait automatiquement et sans rien dire a personne, le jour ou y'a un pb l'utilisateur se retrouve comme un con. Tous surpris, et ne comprenant pas.

        A mon avis il faudrais mieux qu'il y ai des explications systématiques sur tous les sites de téléchargement (comme c fait sur kernel.org par exemple). Au moins comme ça l'utilisateur est au courant, et c'est à quoi ça correspond. Après libre à lui d'en faire ce qu'il veut.
        Perso j'ai pas l'impression que ces info soient très présentes sur les sites, mais bon peut être que je me trompe.

      • [^] # Re: et les checksums c pour les chiens??

        Posté par  (site web personnel) . Évalué à 10.

        Y a pas de signatures sur un miroir GNU par exemple, donc pas sur GCC. Et tous les développeurs ne certifient pas la somme MD5 de leur logiciel avec une clé GPG. Je dirais même que peu de développeurs le font.

        OpenBSD n'utilise pas beaucoup GPG par exemple. Or il ne sert à rien de donner une somme MD5 dans un bête fichier : l'intrus peut remplacer l'archive par son archive infectée, et remplacer la somme MD5 de l'archive propre par celle de l'archive infectée.

        • [^] # Re: et les checksums c pour les chiens??

          Posté par  . Évalué à 10.

          md5 sert à vérifier l'intégrité des données pour le transfert qui a eu lieu entre le serveur et le client . Donc oui il sert à quelque chose et il fait bien son boulot.

          Si on veut sécuriser un fichier il faut, comme tu le dis, signer avec GPG, parce que c'est bien deux choses différentes.

        • [^] # Re: et les checksums c pour les chiens??

          Posté par  (site web personnel) . Évalué à 4.

          De toute façon, une somme MD5 ne sert à rien d'autre qu'à vérifier que le fichier qu'on vient de télécharger et le même que celui qui se trouve sur le serveur. Ainsi, on sait s'il y a eu (ou non) un prblème lors du transfert. En aucun cas cette somme MD5 ne peut-être utilisée pour certifier que le fichier et conforme et qu'il n'a pas été modifié par un w4rl0rdZ de passage. C'est là qu'interviennent PGP, GnuPG et compagnie...

      • [^] # Re: et les checksums c pour les chiens??

        Posté par  (site web personnel) . Évalué à 7.

        La signature sur tes paquets Debian ne sert à pas grand chose si le mainteneur du paquet a récupéré la version corrompue !!!

      • [^] # gpg ???

        Posté par  . Évalué à 9.

        Le problem de gpg c'est qu'il faut comprendre comment il fonctionne.
        Si quelqu'un pouvait m'expliquer comment verifier la signature d'un fichier.
        Sachant que pour verifier la signature, il fait recuperer la clef publique, on pourrait imaginer qu'une personne modifie le fichier, le signe avec un paire de clef et mette la clef publique a disposition. Du coup, la signature est correct. Comment etre sure que l'on a bien la bonne clef publique d'une personne, sans rencontrer cette personne et qu'elle nous la donne en main propre?

        • [^] # Re: gpg ???

          Posté par  (site web personnel) . Évalué à 5.

          > Comment etre sure que l'on a bien la bonne clef publique d'une personne, sans rencontrer cette personne et qu'elle nous la donne en main propre?

          Je t'aide : c'est écrit en toutes lettres sur [ http://www.keyserver.net/en/info.html#nr3(...) ]. À la rubrique « Certification and Trust », il est écrit « Unless you physically received a key [...] the best way to verify the authenticity of a key is to compare its fingerprint. Call the purported owner of the key you want to verify. Ask him to read you the fingerprint of his Private Key: It has to match that of his Public Key ».

          Pas pratique ? Tu n'as pas le numéro du mainteneur ? Eh bien dans ce cas-là, il y a la signature de clés. Par exemple, si je regarde la clé de Martin Schulze (responsable sécurité de Debian) dispo à [ http://search.keyserver.net:11371/pks/lookup?template=netensearch%2(...) ], je m'aperçois que la clé a été signée par une tétrachiée de personnes connues. Je peux donc présumer que c'est la bonne. Ça s'appelle un « réseau de confiance » (Web Of Trust) et c'est difficile à rendre caduc, dans la mesure où, si tu es sûr de la clé identifiant un (ou mieux, plusieurs) de ceux qui ont signé la clé que tu veux vérifier, tu peux raisonnablement faire confiance à celle-ci.

          L'alternative c'est les certificats personnels délivrés par des boîtes comme Thawte, où tu peux juste faire une vérification. Désavantage, si les serveurs de la boîte ne sont pas sûrs, tout le système s'écroule et il y aura probablement beaucoup de dégâts avant que quelqu'un se rende compte que les clés ne sont plus les bonnes (c'est ça, le problème de la centralisation). Enfin, c'est mon opinion, hein, mais je trouve le système PGP assez élégant et raisonnablement pratique...

          Envoyé depuis mon PDP 11/70

          • [^] # Re: gpg ???

            Posté par  . Évalué à 2.

            Je trouve que le web of trust est une chouette idée quand elle est en phase ascendante. La confiance augmente de plus en plus. Mais en phase de crise comme ici, ca se casse joliment la figure.

            Je raye de ma liste le root du serveur ftp. on ne peut pas lui faire confiance. Je raye aussi tout ceux qui lui ont fait confiance jusque là. Je raye aussi tous ceux qui ont été en contact avec les gens rayés. Et ainsi de suite.

            Au final, je décide de couper en petit morceaux mon cable réseau. ;)

            Il me semble que dans IRL, on a un système beaucoup plus sain. On ne fait pas confiance à la probité des individus, on fait confiance à la multitude.

            Les gens sont faillibles. Mais les méchants sont peu nombreux.

            Il est très difficile de s'attaquer à l'urne du bureau de vote car la vigileance est répartie sur la multitude. On fait baisser la pression sur les individus en évitant le plus possible la centralisation.
            Autres exemples:
            les exécutions aux USA: trois bourreaux pour une seringue efficace.
            Système de protection de nolog: trois personnes doivent être réunies pour déverouiller l'accés aux logs.

            En pratique, je ne pense donc pas que j'ai envie de reposer sur Martin Schulze, Twate, ou Fabien Penso. Je vais au contraire choisir au hasard deux personnes inconnues (un hurdiste malais et un windozien unijambiste) et leur proposer une association. On s'occupera entre nous de la sécurité de nos machines et on tachera d'être vigileants ensemble, en se méfiant entre nous.

            Comment baser de la confiance sur de la méfiance ?
            On va avoir besoin de se réunir dans un lieu sûr, sécurisé, audité, clos, déconnecté du monde, franc.
            L'association a juste besoin d'un lieu de réunion.

            On n'a pas besoin d'information fiable, d'une autorité, d'un reseau, d'un secret, d'un point central. On veut notre local.

            Je ne vois pas encore de tels lieux apparaitre. Les first jeudis ne sont qu'une approche.

    • [^] # Re: et les checksums c pour les chiens??

      Posté par  (site web personnel) . Évalué à 10.

      Tout à fait, pour les packages importants sur un serveur (ou même une workstation), il est essentiel de vérifier les checksums MD5 et/ou une signature GPG si elle existe (ce qui devrait être obligatoire).

      Perso, je vérifie toujours les signatures pour mes packages "critiques" : GPG, Apache, OpenSSH, OpenSSL, Bind.

      Pour ceux qui utilisent les packages de leur distrib (genre RPM de RedHat ou Madnrake), ils fournissent toujours des checksums MD5 avec. Celui qui ne les utilise pas, doit être crucifié en place publique ;-)

      • [^] # Re: et les checksums c pour les chiens??

        Posté par  . Évalué à 10.

        Sur ce coup la vérif du MD5 aurait marché... Tout simplement parce que le gland qui est venu posé son trojan n'a pas calculé de MD5 pour celui-ci et a laissé l'ancien.
        Il y a quelques temps il y a eu le même problême avec irssi, le tarball était infecté, mais le malotru avait cette fois calculé le MD5 de la merde qu'il allait poser. Dans ce cas, tu téléchargeais une version vérolée, tu vérifiais avec md5... Et "c'est bon j'peux y aller".
        Ce qu'il faut véritablement c'est un système type GPG pour prévenir ce genre de daubes.

        • [^] # Re: et les checksums c pour les chiens??

          Posté par  . Évalué à 10.

          Sur Freebsd avec les ports, la verification de la signature des sources est automatique. Comme ca on s'embete pas, et on est raisonnablement sur que tout va bien se passer. D'ailleurs c'est avec ce systeme que le gars du weblog a vu qu'il y avait un probleme, le check MD5 ayant echoué FreeBSD a refusé d'installer le port.

          • [^] # Re: et les checksums c pour les chiens??

            Posté par  . Évalué à 9.

            Sur Freebsd avec les ports, la verification de la signature des sources est automatique.
            Le problème est que la version dans /usr/src/crypto que tu cvsup de freebsd.org est vérolée, dans ce cas y'a pas eu de checksum...
            Chez freebsd ils ont pas vérifié le md5 avant de l'inclure dans les sources ! Oh les vilains ;)

    • [^] # Re: et les checksums c pour les chiens??

      Posté par  . Évalué à -5.

      Faire confiance aux signatures/checksum c'est pas forcement bon non plus. Si des petits malins arrivent a pirater le ftp d'openbsd, rien n'interdit de penser qu'ils peuvent recuperer une cle privee et generer des signatures valides... bon ok il faut aussi deviner la passphrase pour debloquer la cle, mais avec les agents...

      A+

      -1 pcq parano

  • # Pffff, openssh ça craint trop niveau sécu...

    Posté par  . Évalué à 10.

    ... je vais me reinstaller telnet

  • # heu... j'ai pas bien compris le weblog

    Posté par  . Évalué à 1.

    Il fait quoi le script ?

    Il ouvre juste une connexion sur une machine ??

    • [^] # Re: heu... j'ai pas bien compris le weblog

      Posté par  . Évalué à 10.

      Oui, il se connecte sur le port 6667 d'une machine (qui ne répond plus d'ailleurs sur ce port), attache les fd 0,1 et 2 sur le socket et fait un exec de /bin/sh

      Un reverse telnet quoi ...

      C'est le meme genre de chose que pour le trojan irssi

      • [^] # Re: heu... j'ai pas bien compris le weblog

        Posté par  . Évalué à 10.

        Ah bah il suffit d'effacer /bin/sh pour ne pas avoir de problème alors...

      • [^] # Re: heu... j'ai pas bien compris le weblog

        Posté par  . Évalué à 6.

        y'a moyen d'avoir des temoignages de ce qu'ils ont fait sur une machine qui s'est fait avoir ? juste pour verifier ... :-/

        • [^] # Re: heu... j'ai pas bien compris le weblog

          Posté par  . Évalué à 6.

          Ben à peu près n'importe quoi.
          Le truc c'est que ça ouvrait un shell avec les droits de l'utilisateur lançant make. Si c'était root, ils ont pu installer tous les rootkits du monde, lancer un démon ftp pour se faire un dump warez, un démon irc pour dire des trucs que la morale réprouve sans se faire coincer, etc.

  • # OpenSSH Security Advisory

    Posté par  . Évalué à 10.

    Niels Provos annonce sur les listes d'Open :

    "Systèmes infectés :
    OpenSSH version 3.2.2p1, 3.4p1 et 3.4 sont infectés sur le FTP d'OpenBSD et probablement d'autres miroirs ... L'infection a eu lieu entre le 30 et 31 juillet ...

    Impact :
    ...(les systèmes avec OpenSSH installé entre ces deux dates sont foutus) ...

    Solution :
    ...Vérifiez vos MD5 :
    MD5 (openssh-3.4p1.tar.gz) = 459c1d0262e939d6432f193c7a4ba8a8
    MD5 (openssh-3.4p1.tar.gz.sig) = d5a956263287e7fd261528bb1962f24c
    MD5 (openssh-3.4.tgz) = 39659226ff5b0d16d0290b21f67c46f2
    MD5 (openssh-3.2.2p1.tar.gz) = 9d3e1e31e8d6cdbfa3036cb183aa4a01
    MD5 (openssh-3.2.2p1.tar.gz.sig) = be4f9ed8da1735efd770dc8fa2bb808a
    "

    Le plus drôle (enfin, si c'est drôle) c'est que le demime sur les dites listes a viré son pgp-signature ;-)

  • # Ne pas compiler en root :

    Posté par  (site web personnel) . Évalué à 10.

    «Some people will build it "normal" privileges and install it as root: they will get a shell with "normal" privileges. Other people will build it with "root" privileges and the shell will have "root" privileges.»

    Ben voilà maintenant je comprends pourquoi...

    • [^] # Re: Ne pas compiler en root :

      Posté par  (site web personnel) . Évalué à -1.

      En fait le make install devrait aussi se faire en mode utilisateur...

      • [^] # Re: Ne pas compiler en root :

        Posté par  . Évalué à 1.

        Ah ben non !
        Si le "make install" se fait en mode utilisateur, n'importe qui pourrait installer ce qu'il veut dans /usr/local/bin !
        Regarde dans ton $PATH ... Je viens de vérifier sur une Mandrake 8.1 et une Slack 8.0 : /usr/local/bin (l'emplacement d'installation par défaut d'openssh) est placé avant /bin et /usr/bin !!!
        On parlait bien de sécurité, non ? :-)

        • [^] # Re: Ne pas compiler en root :

          Posté par  . Évalué à 5.

          Quand on installe les gros logiciels (mais pourquoi pas pour les autres ?), on commence par creer un user dedie a ce soft. (utilisateur+groupe "oracle" par exemple). puis on cree un repertoire /usr/local/oracle par exemple et on donne les droits sur ce repertoire au user oracle.

          du coup tu peux compiler et installer sans etre root, tu peux aussi autoriser quelques users a utiliser le soft en leur affectant le groupe "oracle".

          • [^] # Re: Ne pas compiler en root :

            Posté par  . Évalué à 2.

            Je voudrais pas avoir l'air d'être tatillon, mais selon le Filesystem Hierarchy Standard ( http://www.pathname.com/fhs/(...) ) , il faut mettre les gros paquetages, ou groupes de paquetages, (Oracle, OpenOffice.org, Apache...) dans /opt/nom_qui_décrit_le_paquetage.

            Ils vont mème jusquà dire "No other directories, except those listed below, may be in /usr/local after first installing a FHS-compliant system."

            Au passage, le "More control and package management using package users hint" (
            http://hints.linuxfromscratch.org/hints.shtml(...) , l'index des hints, le lien complet ne veut pas passer.)
            donne des scripts pour automatiser les install avec utilisateur dédié.

        • [^] # Re: Ne pas compiler en root :

          Posté par  . Évalué à 3.

          Euh oui ca me parrait 'normal' comme comportement.
          En admettant que la machine est securisee, personne sauf root ne peut ecrire dans /usr/local/

          Or mettre /usr/local avant le reste dans le $PATH permet au root de changer les versions des programmes, sans pour autand flinguer les paquets:

          Programme XYZ installe dans /usr/bin, on decouvre un probleme, vite on compile une version 'temporaire' a la main dans /usr/local ,les users utilisent cette version directement, sans s'en rendre compte... quand le paquet corrige sort, on l'installe et on degage la version temporaire de /usr/local...

          La correction est transparente pour les utilisateurs... et c'est securise

          Dans le meme genre d'idee ~/bin est generalement placer en premier dans le $PATH, comme ca un utilisateur qui veut une version differente d'un programme installe dans /usr/, peut le compiler chez lui et sera utilise automatiquement...

          Pour ceux qui suive la mailling debian-user-french, il y a eu une discution (qui a dit un troll?) sur le fait que vi etait present dans /bin et /usr/bin , c'est le meme principe:
          dans /usr/bin une version 'complete' a utiliser tous les jours avec plein de dependances dans /usr et dans /bin une version de secours avec moins de dependance (en tous cas aucune dans /usr ) pour les jours ou la partoche /usr est dans les choux.

        • [^] # Utilisez GNU Stow

          Posté par  . Évalué à 4.

          En effet, il ne faut pas que n'importe qui puisse écrire dans /usr/local. Mais rien n'empêche un utilisateur spécifique d'écrire dedans ... Sur mes machines (Debian), /usr/local est SGID src. Donc tout utilisateur faisant partie du groupe src peut écrire dans /usr/local. Reste maintenant à savoir qui mettre dans le groupe src. Y mettre tous les utilisateurs est certainement une erreur !

          De plus, afin de faciliter l'installation et la suppression de programmes externes à la distribution, il existe un outil très pratique : GNU Stow [http://www.gnu.org/software/stow/(...)]. Pour l'utiliser, on a un répertoire /usr/local/stow dans lequel on crée un répertoire par application que l'on installe à la main. Lorsqu'on compile un soft qui utilise autoconf, il suffit de passer --prefix=/usr/local/stow/mon-soft à ./configure. Une fois le make install réalisé (avec un utilisateur qui a le droit d'écrire dans /usr/local/stow, pas forcément root), il suffit de faire "stow mon-soft" pour créer des liens symboliques depuis le répertoire mon-soft vers les répertoires adaptés dans /usr/local.

          Ensuite, si vous voullez enlever un soft, il suffit de faire "stow --delete mon-soft" et de supprimer le répertoire (on n'est pas obligé de le faire dans l'ordre là).

          Avantages de stow :
          - on n'est pas obligé d'être root et on garde une bonne sécurité (à mon avis) ;
          - on peut désinstaller facilement un soft ;
          - on évite d'écraser par erreur des fichiers déjà existants : stow prévient lors d'un conflit.

          • [^] # Re: Utilisez GNU Stow

            Posté par  . Évalué à 2.

            pour compiler avec stow, je préfère faire :
            configure --prefix=/usr/local
            make
            make install prefix=/usr/local/stow/mon-soft/

            Comme ça, si le soft utilise 'prefix' (dans des fichiers d'exemple de config pour l'utilisateur par exemple), on ne voit pas stow/mon-soft/.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.