Posté par Psychofox (Mastodon) .
En réponse au journal Au voleur.sh.
Évalué à 4.
Dernière modification le 04 août 2017 à 11:35.
Note: il fallait faire une typo dans sa liste des packages pour être « infecté » par le mauvais package.
Le problème c'est pas tant nodejs que la façon dont est géré la sécurité dans tous les systèmes de packaging de librairies/modules. On tape volontier sur nodejs/npm mais c'est la même chose pour cpan, les rubygems, pip, les pléthores de librairies java, .net ou autre que tu peux utiliser pour développer ton application.
Est-ce que les projets pip, rubygems, packages.debian.org ou epel font de l'analyse systématique de tout code qui va dans leurs dépôt pour vérifier que ce genre de backdoor n'apparaisse pas ? Pas à ma connaissance. On se base essentiellement sur la confiance que l'on a envers les mainteneurs des packages.
# npm
Posté par Psychofox (Mastodon) . En réponse au journal Au voleur.sh. Évalué à 4. Dernière modification le 04 août 2017 à 11:35.
Note: il fallait faire une typo dans sa liste des packages pour être « infecté » par le mauvais package.
Le problème c'est pas tant nodejs que la façon dont est géré la sécurité dans tous les systèmes de packaging de librairies/modules. On tape volontier sur nodejs/npm mais c'est la même chose pour cpan, les rubygems, pip, les pléthores de librairies java, .net ou autre que tu peux utiliser pour développer ton application.
Est-ce que les projets pip, rubygems, packages.debian.org ou epel font de l'analyse systématique de tout code qui va dans leurs dépôt pour vérifier que ce genre de backdoor n'apparaisse pas ? Pas à ma connaissance. On se base essentiellement sur la confiance que l'on a envers les mainteneurs des packages.