je vais me faire l'avocat du diable, mais il parle de pyenv. Du coup tu dis:
c'est tout de même mieux qu'un code hébergé sur un dépôt github dont on ignore la maîtrise.
Or, pyenv est hébergé sur github. Donc faire curl github.com/pyenv | bash c'est mal. Mais faire git clone github.com/pyenv && pyenv/bin/pyenv c'est plus sécurisé?
Malheureusement si tu veux tester un logiciel, tu vas tôt ou tard lancer un binaire précompilé, ou un script que tu n'auras pas relu.
Maintenant, ouais, je hurle contre le curl | bash pour plein d'autres raisons. Mais là, ce qui m'ennuie c'est que ça devient du cargo cult, tout le monde dit que c'est mal, tout le monde hurle en expliquant que c'est mal mais plus personne ne donne vraiment de raisons. Petite histoire : j'ai connu des devs qui refusaient absolument d'utiliser strcpy (c'est bien) mais sans avoir compris les raisons. Du coup, on voyait des contorsions assez tordues dans des cas idiots, genre strncpy(dst, src, strlen(src)); [CRANE D'OCTANE QUI SE FRACASSE CONTRE LE CLAVIER QUAND IL LIT CA EN CODE REVIEW].
Enfin voilà, tout ça pour dire que curl | bash faut pas utiliser, mais faut pas se bercer d'illusions non plus sur les paquets de la distro magiquement vérifiés.
Si cet éditeur se fait pirater au point de se faire voler sa clé privée, il lui suffit de révoquer son certificat publiquement, et le gestionnaire de paquets ne fera plus confiance aux paquets signés par lui.
Parceque se pose la question du code review de l'éditeur. Et si le maintener[1] fait un git clone && debuild etc... alors le risque d'apt-get install pyenv est il plus faible qu'un curl | bash ? En vrai? Et comment as tu vérifié que le maintener a bien géré l'install? C'est pas en faisant confiance à son certificat....
[1] no shame pour le maintener je sais que c'est un boulot difficile
[^] # Re: XDG
Posté par octane . En réponse à la dépêche Environnement moderne de travail Python. Évalué à 6.
je vais me faire l'avocat du diable, mais il parle de pyenv. Du coup tu dis:
Or, pyenv est hébergé sur github. Donc faire curl github.com/pyenv | bash c'est mal. Mais faire git clone github.com/pyenv && pyenv/bin/pyenv c'est plus sécurisé?
Malheureusement si tu veux tester un logiciel, tu vas tôt ou tard lancer un binaire précompilé, ou un script que tu n'auras pas relu.
Maintenant, ouais, je hurle contre le curl | bash pour plein d'autres raisons. Mais là, ce qui m'ennuie c'est que ça devient du cargo cult, tout le monde dit que c'est mal, tout le monde hurle en expliquant que c'est mal mais plus personne ne donne vraiment de raisons. Petite histoire : j'ai connu des devs qui refusaient absolument d'utiliser strcpy (c'est bien) mais sans avoir compris les raisons. Du coup, on voyait des contorsions assez tordues dans des cas idiots, genre strncpy(dst, src, strlen(src)); [CRANE D'OCTANE QUI SE FRACASSE CONTRE LE CLAVIER QUAND IL LIT CA EN CODE REVIEW].
Enfin voilà, tout ça pour dire que curl | bash faut pas utiliser, mais faut pas se bercer d'illusions non plus sur les paquets de la distro magiquement vérifiés.
Parceque se pose la question du code review de l'éditeur. Et si le maintener[1] fait un git clone && debuild etc... alors le risque d'apt-get install pyenv est il plus faible qu'un curl | bash ? En vrai? Et comment as tu vérifié que le maintener a bien géré l'install? C'est pas en faisant confiance à son certificat....
[1] no shame pour le maintener je sais que c'est un boulot difficile