Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
Je ne vois pas trop comment wget ou curl pourraient détecter cela.
Une solution serait de détecter quand la sortie standard est redirigée, comme le font grep ou ls, et dans ce cas de ne rien faire.
Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.
Posté par foobarbazz .
Évalué à 2.
Dernière modification le 22 octobre 2018 à 11:31.
Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.
Il y a plein de raisons légitimes à vouloir piper un document téléchargé… Ce n'est pas sans raison que c'est le comportement par défaut.
Le seul cas qui pose problème c'est les utilisateurs qui exécutent ce genre de commande sans avoir forcement conscience des risques.
Rappelons aussi que curl foo > bash est à quelques fichiers près sémantiquement équivalent à wget foo ; chmod +x foo; ./foo, voir même que git clone foo ; cd foo; ./foo.
Il faut juste avoir conscience de ce que peut faire ce genre de commandes.
Yep, et tu noteras que je n'ai pas dis que c'était en soit une bonne idée de blinder le système contre ça.
Mais, j'ai trouvé la question pertinente dans le sens technique. De la même façon que certains interpréteurs de commandes forcent validation d'une commande copiée/collée quoi.
D'autant plus que, bah, j'ai été confronté à des gens qui font ce genre de trucs sans lire le script, pour installer npm par exemple, logiciel qui n'a aucun respect pour le système qui l'entoure.
Au taf, à cause de ce genre de conseils pourris sur le net, j'ai perdu plusieurs jours à réinstaller des systèmes dans un état fonctionnel (parce que, non, en 1 an, je n'ai pas eu le temps de mettre en place une politique de restauration des machines… je ne suis pas payé en tant qu'admin, mais en tant que dev, à la base… je manque à la fois de compétences pour déployer les bons outils, et de temps pour essayer de le faire).
C'est toujours dur de convaincre les gens de ne pas recommander une telle méthode (coucou Rust).
Ben le problème initial qui nécessite cette bidouille est toujours la, les gens n'y peuvent pas grand chose si les distrib ne sont pas foutue de se mettre d'accord sur une format de package "sûr" commun et qui passe aussi bien que ça.
Les fautifs sont-ils vraiment les utilisateurs de cette méthode? Plutôt de perdre ton temps à convaincre les de ne pas recommander une telle méthode, ce serait peut-être plu efficace d'essayer de convaincre les auteurs de la source du problème de régler le problème initial, tu ne penses pas?
Ce n'est pas en soignant les blessures que tu empêcheras les suivants de se blesser, mais en stoppant la source des blessures.
Le format des paquets n'a aucun lien avec le problème présenté ici.
Le truc discuté ici consiste à copier/coller une ligne de shell afin de télécharger automatiquement tout le bouzin et d'exécuter des commandes.
C'est l'équivalent d'un fichier zip qui contient un runme.sh. Le zip en question peut contenir autant de cochonneries que la méthode décriée.
Si tu veux en faire un paquet à télécharger depuis un site web quelquonque, c'est le même résultat : il peut contenir n'importe quoi. Même s'il existait un format de paquet accepté par toutes les distributions.
Posté par Psychofox (Mastodon) .
Évalué à 6.
Dernière modification le 24 octobre 2018 à 13:57.
En fait j'ai tendance à penser des fois que la méthode du curl pipé vers bash est moins dangereuses que certaines autres. Au moins tu peux lire le script et voir ce qu'il fait relativement facilement.
Quand c'est un package il faut d'abord soit le mettre dans un bac à sable isolé, soit l'extraire quelque part pour l'étudier.
Après le script spaghetti qui va aller chercher d'autres scripts ailleurs là ça devient ingérable (hello netdata.io) et t'as plus qu'à serrer les fesses et faire confiance à l'upstream, à ton dns, le proxy qui fait du mitm dans ta boite et que sais-je encore.
Le format des paquets n'a aucun lien avec le problème présenté ici.
Le rapport c’est que distribuer son logiciel proprement en créant un dépôt ad-hoc et des packages pour une distribution est déjà chiantissime alors le faire pour toutes les distributions est inimaginable hormis pour les plus gros projets.
Le plus simple moyen de distribution est MacPorts mais la cible est spécifique au possible.
Le vieux combo «configure && make all install» est largement délaissé — pour de bonnes raisons, l’investissement temps-bénéfice pour apprendre les Auto-Tools est assez décourageant, et même si on a tout bien fait, créer son package pour une distribution de premier plan comme Debian ou Ubuntu est absurdement difficile.
On parle de truc qui ne sont pas dans les dépôts des distributions. En quoi avoir un format de paquet standardisé vas permettre d'être quasi-certain qu'un paquet récupéré sur un site quelconque ne contient pas de cochonneries ?
Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.
Posté par Michaël (site web personnel) .
Évalué à 4.
Dernière modification le 30 octobre 2018 à 14:45.
Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.
Ce qui augmente la confiance c'est d'avoir un contenu cryptographiquement signé avec un checksum publié séparément.
Rien n'interdit par exemple de faire un serveur qui publie un script différent en fonction des paramètres du client (IP, user agent, plage horaire) ce qui pourrait constituer un vecteur d'attaque.
Avec un paquet hébergé ad-hoc c'est un peu mieux – faire confiance à une clef GPG est plus restrictif que de faire confiance à un serveur web – l'idéal serait d'avoir des sources différentes pour le checksum et pour le paquet.
faut pas prendre de l'info sensible d'un site web en http (pour éviter un MiTM qui modifierait le contenu)
ça ne suffit pas prendre de l'info d'un site web en https : en fait n'importe qui peut avoir un certificat valide, donc faut garantir que c'est le bon domaine…
même si on a le bon domaine, faudrait que ça soit vraiment lui qui réponde (DNSSEC? proxy?)
et quand on a tout ça, bon ben faut pas exécuter directement le contenu dans un shell sans réfléchir… (encore moins avec sudo…)
et ça serait mieux si le contenu était signé GPG, que la clé soit de confiance et qu'un café soit offert.
(un exemple sur rvm.io: \curl -sSL https://get.rvm.io | bash -s stable )
# C'est vieux, mais toujours d'actualité
Posté par Glandos . Évalué à 3.
Merci pour le (vieux) lien. C'est toujours dur de convaincre les gens de ne pas recommander une telle méthode (coucou Rust).
Ceci dit, est-ce que ce comportement n'a pas été modifié dans curl ? Ça ne changerait que moyennement le problème, mais bon.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par liberforce (site web personnel) . Évalué à 5.
Je t'avoue que j'avais vu l'article circuler et pas vu sa date. Mais comme toi je vois régulièrement des services qui proposent ce genre de méthode d'installation, et pas vraiment d'avertissement. Je ne sais pas s'il y a eu des modifications dans curl mais je ne vois pas ce que ça changerait: c'est le serveur web qui est malicieux, et altèrerait le contenu du ficher. Je ne vois pas trop comment wget ou curl pourraient détecter cela.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par freem . Évalué à 2.
Une solution serait de détecter quand la sortie standard est redirigée, comme le font grep ou ls, et dans ce cas de ne rien faire.
Ça casserait tous ces comportements sales, mais ça forcerait les usages légaux à évoluer aussi.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par foobarbazz . Évalué à 2. Dernière modification le 22 octobre 2018 à 11:31.
Il y a plein de raisons légitimes à vouloir piper un document téléchargé… Ce n'est pas sans raison que c'est le comportement par défaut.
Le seul cas qui pose problème c'est les utilisateurs qui exécutent ce genre de commande sans avoir forcement conscience des risques.
Rappelons aussi que
curl foo > bashest à quelques fichiers près sémantiquement équivalent àwget foo ; chmod +x foo; ./foo, voir même quegit clone foo ; cd foo; ./foo.Il faut juste avoir conscience de ce que peut faire ce genre de commandes.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par freem . Évalué à 2.
Yep, et tu noteras que je n'ai pas dis que c'était en soit une bonne idée de blinder le système contre ça.
Mais, j'ai trouvé la question pertinente dans le sens technique. De la même façon que certains interpréteurs de commandes forcent validation d'une commande copiée/collée quoi.
D'autant plus que, bah, j'ai été confronté à des gens qui font ce genre de trucs sans lire le script, pour installer npm par exemple, logiciel qui n'a aucun respect pour le système qui l'entoure.
Au taf, à cause de ce genre de conseils pourris sur le net, j'ai perdu plusieurs jours à réinstaller des systèmes dans un état fonctionnel (parce que, non, en 1 an, je n'ai pas eu le temps de mettre en place une politique de restauration des machines… je ne suis pas payé en tant qu'admin, mais en tant que dev, à la base… je manque à la fois de compétences pour déployer les bons outils, et de temps pour essayer de le faire).
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Zenitram (site web personnel) . Évalué à -2.
Ben le problème initial qui nécessite cette bidouille est toujours la, les gens n'y peuvent pas grand chose si les distrib ne sont pas foutue de se mettre d'accord sur une format de package "sûr" commun et qui passe aussi bien que ça.
Les fautifs sont-ils vraiment les utilisateurs de cette méthode? Plutôt de perdre ton temps à convaincre les de ne pas recommander une telle méthode, ce serait peut-être plu efficace d'essayer de convaincre les auteurs de la source du problème de régler le problème initial, tu ne penses pas?
Ce n'est pas en soignant les blessures que tu empêcheras les suivants de se blesser, mais en stoppant la source des blessures.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Kerro . Évalué à 6.
Le format des paquets n'a aucun lien avec le problème présenté ici.
Le truc discuté ici consiste à copier/coller une ligne de shell afin de télécharger automatiquement tout le bouzin et d'exécuter des commandes.
C'est l'équivalent d'un fichier zip qui contient un
runme.sh. Le zip en question peut contenir autant de cochonneries que la méthode décriée.Si tu veux en faire un paquet à télécharger depuis un site web quelquonque, c'est le même résultat : il peut contenir n'importe quoi. Même s'il existait un format de paquet accepté par toutes les distributions.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 24 octobre 2018 à 13:57.
En fait j'ai tendance à penser des fois que la méthode du curl pipé vers bash est moins dangereuses que certaines autres. Au moins tu peux lire le script et voir ce qu'il fait relativement facilement.
Quand c'est un package il faut d'abord soit le mettre dans un bac à sable isolé, soit l'extraire quelque part pour l'étudier.
Après le script spaghetti qui va aller chercher d'autres scripts ailleurs là ça devient ingérable (hello netdata.io) et t'as plus qu'à serrer les fesses et faire confiance à l'upstream, à ton dns, le proxy qui fait du mitm dans ta boite et que sais-je encore.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Michaël (site web personnel) . Évalué à 3.
Le rapport c’est que distribuer son logiciel proprement en créant un dépôt ad-hoc et des packages pour une distribution est déjà chiantissime alors le faire pour toutes les distributions est inimaginable hormis pour les plus gros projets.
Le plus simple moyen de distribution est MacPorts mais la cible est spécifique au possible.
Le vieux combo «configure && make all install» est largement délaissé — pour de bonnes raisons, l’investissement temps-bénéfice pour apprendre les Auto-Tools est assez décourageant, et même si on a tout bien fait, créer son package pour une distribution de premier plan comme Debian ou Ubuntu est absurdement difficile.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Kerro . Évalué à 3.
On parle de truc qui ne sont pas dans les dépôts des distributions. En quoi avoir un format de paquet standardisé vas permettre d'être quasi-certain qu'un paquet récupéré sur un site quelconque ne contient pas de cochonneries ?
Ou au moins être plus confiant qu'avec une ligne de commande venant du même site, administré par les mêmes personnes.
[^] # Re: C'est vieux, mais toujours d'actualité
Posté par Michaël (site web personnel) . Évalué à 4. Dernière modification le 30 octobre 2018 à 14:45.
Ce qui augmente la confiance c'est d'avoir un contenu cryptographiquement signé avec un checksum publié séparément.
Rien n'interdit par exemple de faire un serveur qui publie un script différent en fonction des paramètres du client (IP, user agent, plage horaire) ce qui pourrait constituer un vecteur d'attaque.
Avec un paquet hébergé ad-hoc c'est un peu mieux – faire confiance à une clef GPG est plus restrictif que de faire confiance à un serveur web – l'idéal serait d'avoir des sources différentes pour le checksum et pour le paquet.
# Résumé ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10. Dernière modification le 19 octobre 2018 à 15:08.
(un exemple sur rvm.io:
\curl -sSL https://get.rvm.io | bash -s stable)[^] # Re: Résumé ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Un autre exemple avec du python pour changer : https://pre-commit.com/#install
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.