Un développeur JavaScript estime que l'écosystème Node.js est « chaotique et peu sûr »
Un développeur JavaScript estime que l'écosystème Node.js est « chaotique et peu sûr »
Et voici pourquoi
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 ».
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 ?
:fleche: Qu'en pensez-vous ?
:fleche: 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 ?
:fleche: Avez-vous l'habitude d'auditer vos dépendances ?
:fleche: Comment trouvez-vous l'écosystème Node.js ? Quels sont ses avantages et inconvénients ?
Voir aussi :
:fleche: 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
:fleche: 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 ?
:fleche: Quel est l'intérêt d'écrire ou réécrire un logiciel en JavaScript ? Partagez votre expérience
:fleche: 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
:fleche: 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
C'est la même chose pour les développements Java et .Net !
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 :-)
