Un développeur JavaScript estime que l'écosystème Node.js est « chaotique et peu sûr »
Et voici pourquoi

Le , par Michael Guilloux, Chroniqueur Actualités
Améliorer ou étendre les fonctionnalités d'un langage, un EDI ou une plateforme quelconque au moyen d'extensions ou de packages est une pratique très populaire dans le monde moderne de la technologie. Cela permet d'éviter qu'un programme devienne un bloatware puisqu'il ne va intégrer que les fonctionnalités les plus basiques et les plus communes, et laisser à l'utilisateur le soin d'installer les fonctionnalités supplémentaires dont il aura besoin.

Aujourd'hui, tous les langages semblent fonctionner de cette manière : se doter de certaines fonctionnalités basiques ou communes et permettre aux utilisateurs d'installer des packages pour des fonctionnalités spécifiques. Précisons aussi qu'un package peut avoir des dépendances, c'est-à-dire nécessiter l'installation d'autres packages pour fonctionner. On peut donc se retrouver facilement avec de nombreuses dépendances imbriquées dans le code d'un logiciel.

Cette manière de fonctionner peut toutefois être un problème pour le développement logiciel : maintenance forcée si une dépendance est supprimée ou encore propagation rapide d'un code malveillant à des milliers, voire des millions, de logiciels si une dépendance est infectée ou contient une porte dérobée. L'écosystème Node.js n'est pas épargné par ce problème. D'ailleurs, il en serait sérieusement affecté. C'est ce que veut exprimer Casper Beyer, développeur JavaScript et blogueur, lorsqu'il affirme que « l'écosystème Node.js est chaotique et peu sûr ».


Casper Beyer, développeur JavaScript et blogueur

Il insiste notamment sur le problème de sécurité qui découle des paquets. Casper Beyer explique que cela est amplifié par le fait que les développeurs appliquent un peu trop littéralement le principe de ne pas réinventer la roue : créer des paquets uniquement pour éviter aux autres développeurs d'écrire une seule ligne de code.

C'est le cas par exemple des paquets comme is-odd ou is-number. Le paquet is-odd permet de vérifier si un nombre est un nombre impair, juste ça, et il aurait environ 500 000 de téléchargements par jour. « En passant par l'arbre des dépendances, j'ai trouvé que des centaines de projets en dépendent, mais surtout des grands projets comme Webpack, BrowserSync et Babel », ajoute Casper Beyer. Le paquet is-number aurait, quant à lui, près de deux millions de téléchargements par jour et le paquet is-odd en dépend.

Un autre paquet is-even (qui permet de vérifier si un nombre est un nombre pair) montre encore le caractère parfois redondant de certains paquets, puisqu'il dépend du paquet is-odd. C'est vrai qu'il ne faut pas réinventer la roue, mais en quoi utiliser l'opération de négation ici serait réinventer la roue ? S'interroge le développeur JavaScript. Pour lui, cela revient simplement à donner beaucoup trop de puissance à un paquet qui aurait dû être un simple module ou faire appel à un opérateur élémentaire. Trop de puissance parce que, selon lui, ces dépendances qu'il qualifie de « non-sens » sont difficiles sinon presque impossibles à auditer manuellement en raison de leur nombre. Ainsi, en général, personne ne se donne la peine de les auditer avant de les déployer. Donc n'importe qui peut les détourner et y insérer du code malveillant qui serait déployé presque partout où JavaScript est exécuté.

Il souligne qu'il y a des milliers de paquets aussi triviaux (écrits par des centaines d'auteurs anonymes) qui ont des millions de téléchargements par semaine et dont de nombreux projets populaires en dépendent. Tout ce qu'il faut pour un auteur mal intentionné, c'est d'attendre jusqu'à ce que son paquet ait une portée largement suffisante, puis publier une mise à jour avec une charge malveillante qui va se répandre comme une traînée de poudre. Cette stratégie a d'ailleurs déjà été utilisée par un tas d'extensions de navigateur qui ont fini par injecter dans leur code un mineur de cryptomonnaie et exploiter les machines des utilisateurs, bien qu'elles avaient au préalable été examinées par des humains.

Cela dit, il invite les développeurs à être plus responsables : « Ne faites pas confiance aux gestionnaires de paquets, chaque dépendance est écrite par un développeur quelconque quelque part dans le monde et est un vecteur d'attaque potentiel. Cela s'applique à tous les gestionnaires de paquets, mais ces paquets à une ligne font en sorte qu'aucun effort n'est requis », dit-il. Il suggère aux développeurs d'éviter d'utiliser ces dépendances dites « non-sens » et d'écrire eux-mêmes leur code pour ces cas élémentaires, car « écrire du code basique ne réinvente pas la roue. » Il pense aussi que les développeurs devraient auditer manuellement leurs dépendances.

Source : Billet de Casper Beyer

Et vous ?

Qu'en pensez-vous ?
Le problème de dépendances triviales est-il propre l'écosystème Node.js ? Ou est-ce dans le monde Node.js qu'il est pire ?
Avez-vous l'habitude d'auditer vos dépendances ?
Comment trouvez-vous l'écosystème Node.js ? Quels sont ses avantages et inconvénients ?

Voir aussi :

Non, Microsoft n'a pas abandonné C++, C#, etc. pour réécrire ses outils et logiciels en JavaScript : un développeur de la firme fait des précisions
Hyperapp, une bibliothèque JavaScript de 1 ko pour la création d'applications Web front-end, en quoi diffère-t-elle des bibliothèques existantes ?
Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ? Partagez votre expérience
npm : une porte dérobée a été découverte dans le paquet getcookies qui a des dépendances imbriquées avec le paquet populaire Mailparser
npm : un bogue avec le code d'erreur « 418 I'm a teapot » a affecté le registre, empêchant l'utilisation du client npm derrière un proxy


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de grunk grunk - Modérateur https://www.developpez.com
le 09/07/2018 à 8:47
C'est la force et la faiblesse de node.
D'un coté c'est tellement pratique d'installer un paquet en une ligne de code et de gagner de nombreuses heures de développement et d'un autre c'est tellement frustrant de voir le nombre de dépendance qu'on récupère sans vraiment s'en rendre compte.
Très clairement des paquets comme iseven c'est juste ridicule.

J'ai récemment fait un petit outil en js qui s'utilise en ligne de commande.
J'ai ajouté 5 dépendances
- Une gestion des paramètres de ligne de commande
- Une gestion des couleurs d'affichage
- Une gestion de zip
- Une progressbar
- Un utilitaire qui permet de simuler un rm -Rf

Au final je récupère 62 dépendances. J'ai parcourus le code des 5 dépendances que j'ai ajouté pour être à peut près certains de ce que j'allais utiliser , mais j'ai clairement pas le temps de vérifier les dépendances de dépendances de dépendances...
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 09/07/2018 à 10:12
C'est devenu tellement lourd de tirer la terre entière pour une misérable dépendance que ça devient un argument de certaines libs de dire "nodeps".
Avatar de xelab xelab - Membre expérimenté https://www.developpez.com
le 09/07/2018 à 10:39
Cela m'a fait penser à ce billet : https://medium.com/@jdan/i-peeked-in...t-b89f63d21558 (bon ça a 2 ans donc les trucs comme la photo du développeur dans le code ne sont plus d'actualité).
Avatar de hotcryx hotcryx - Membre extrêmement actif https://www.developpez.com
le 09/07/2018 à 10:48
T'as oublié un slash dans ta commande lol:
Code : Sélectionner tout
rm -rf / :aie::aie::aie::aie:
D'où l'importance de connaitre les dev derrières les paquets et n'utilisez que des paquets majeurs.

Pareil pour les libs Perl ou Python.
Grosse galère quand il faut utiliser une nouvelle lib ayant plein de déps sans pouvoir utiliser cpan.

Rem: concernant le bitcoin ou autre code frauduleux, on arrive toujours à remonter à celui qui a injecté ces modifs.
D'où l'importance de ne prendre que des dev en qui on peut faire confiance.
Avatar de ympondaven ympondaven - Nouveau Candidat au Club https://www.developpez.com
le 10/07/2018 à 11:45
faire des packages pour tester si un nombre est pair ou non est contraire a la simplicité.
en math un nombre pair c'est n modulo 2 = 0. il n'y a pas besoin de package pour ca !
Avatar de myk1e myk1e - Nouveau Candidat au Club https://www.developpez.com
le 10/07/2018 à 13:15
Question de noob : du coup, est-ce qu'il faut utiliser "Webpack, BrowserSync et Babel" ? Si oui, quelles seraient les différentes approches pour limiter les risques décrits ?
Avatar de Marco46 Marco46 - Modérateur https://www.developpez.com
le 10/07/2018 à 14:29
Aucun des projets que tu décris n'est une dependencies, il s'agit de devDependencies. L'auteur du billet parle exclusivement des dependencies, même si les paquets en devDependencies posent également problème.

En gros le is-odd finira dans le livrable exécuté par le client, webpack ou babel non, ils vont servir à générer le livrable.
Avatar de Bardotj Bardotj - Membre à l'essai https://www.developpez.com
le 10/07/2018 à 15:03
La*bonne méthode a mes yeux est de dev pour les versions stables des distributions linux (debian, centos) et utiliser les versions packagée des bibliothéques, les mainteneurs des paquets fesant un minimum de revues. Oui cela fera que vous n’aurez pas la dernière feature a la mode mais vous pourrez quand elle sera stable.
Avatar de francortes francortes - Futur Membre du Club https://www.developpez.com
le 18/07/2018 à 8:22
bonjour,

j'ai remplacé les outils de build pré-cités par :

- "rollup" : bundles plus petits, config aisée par fichier export {... } ES6
- "bublé" : moins de fonctionnalités ES6, maos plus rapide * 3 environ

leur graphe de dépendances n'a pas l'air trop déconnant !
Avatar de schlebe schlebe - Futur Membre du Club https://www.developpez.com
le 18/07/2018 à 12:34
Les constatations de l'auteur ne sont pas propres au seul langage node.js !

Là où je travaille, aucune des dépendances n'est vérifiées ou auditées. On prend et on utilise car c'est gratuit.

J'ai bien peur qu'un jour un énorme bug ou, plus grave, une malvaillance volontaire ne foute tout en l'air simplement parce que les responsables IT ont fait aveuglément confiance aux logiciels libres car cela ne leur coûtaient rien.

Wait and see :-)
Contacter le responsable de la rubrique Accueil