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

Le , par Michael Guilloux

148PARTAGES

15  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 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é).
3  0 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 30/07/2018 à 23:45
Citation Envoyé par Beginner. Voir le message

- Que signifie "auditer des dépendances" ?
Cela signifie regarder ce qu'elles font réellement. Donc lire le code dans le détail, exécuter des utilitaires dessus pour vérifier la qualité, couverture de tests, si ils s'exécutent correctement, etc ...

Si on parle de la nouvelle commande npm audit il s'agit d'un service proposé par npm qui liste les failles de sécurité répertoriées pour te dire si tu installes une dépendance qui a un problème. Cf news sur le sujet.

Citation Envoyé par Beginner. Voir le message

- Sinon je n'y connais pas grand chose mais cette question des dépendances m'intrigue... Si on utilise plusieurs paquets et que ces derniers ont des dépendances en commun, est-ce que ces dernières seront installées plusieurs fois ?
Pas dans les dernières versions de npm (ça fait un bon moment je sais plus de quand ça date). Si tu as 2 dépendances qui utilisent la même version d'une dépendance elle n'est installée qu'une seule fois.

Citation Envoyé par Beginner. Voir le message

Est-ce que j'aurais des bouts de code en plusieurs exemplaires dans l'application finale ?
Ça dépend de comment tu buildes ton appli et de si tes outils de build et de gestion de dépendances sont à jour. Normalement non.

Citation Envoyé par Beginner. Voir le message

Ou bien c'est justement un des rôles de certains outils d'éviter ça ?
Oui.

Citation Envoyé par Beginner. Voir le message

- Autre chose j'ai l'impression qu'à cause de ces dépendances on pourrait avoir de grosses surprises concernant la taille de l'application finale, non ? Il est difficile d'en avoir une idée ?
Pour le frontend les bundlers sont capables depuis quelques temps de faire du tree-shaking. C'est à dire qu'ils parcourent le code de ton appli pour n'ajouter au livrable que ce qui est réellement exécuté. Donc ça va même plus loin que d'éviter les doublons, ça exclus aussi le code qui n'est pas exécuté. Par exemple si tu importes lodash et que tu n'utilises pas la fonction add et qu'aucune autre fonction ne l'utilise en dépendance son code ne sera pas ajouté à ton livrable. Ça réduit considérablement la taille des livrables. Mais ça oblige à utiliser un système de module (CommonJS ou ESModules).
2  0 
Avatar de 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".
1  0 
Avatar de schlebe
Nouveau 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 :-)
1  0 
Avatar de 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...
0  0 
Avatar de 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.
0  0 
Avatar de 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 !
0  0 
Avatar de 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 ?
0  0 
Avatar de 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.
0  0 
Avatar de Bardotj
Membre régulier 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.
0  0 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web