
Le registre NPM est un service qui permet aux développeurs de JavaScript de publier et de partager leurs modules de code avec la communauté. Il est utilisé par des millions de projets et de développeurs dans le monde entier. Cependant, il a récemment été victime d’un canular qui a perturbé son fonctionnement et causé des problèmes à de nombreux utilisateurs.
Le référentiel de packages JavaScript open source exploité par GitHub héberge plus de 2 millions de packages et est utilisé par plus de 17 millions de développeurs, selon le site Web NPM.
Le 29 décembre, un package nommé "everything" (tout) a été publié dans le registre, conçu pour installer tous les autres packages publics du registre. Cela a créé un réseau de dépendances à l'échelle du registre qui a effectivement désactivé la possibilité de dépublier des packages sur le site, car les packages dont dépendent d'autres packages ne peuvent pas être dépubliés.
Qu'est-ce qui se trouve derrière le package "everything" ?
En fait, le package "everything" ne contient que 5 sous-packages, publiés sous la portée "@everything-registry", répertoriés comme ses dépendances. Cependant, ces 5 packages parviennent progressivement à intégrer chaque package présent sur l'ensemble du registre NPM en tant que dépendance. Par exemple, "everything" récupère « @everything-registry/chunk-2 », ce qui peut en outre tenter d'extraire plusieurs autres packages du même auteur, tels que « @everything-registry/sub-chunk-1623 ».
Chacun de ces sous-packages (ou « morceaux » comme les appelle l'auteur) comprend finalement environ 800 projets npm comme dépendance.
Considérant que l'auteur de "everything" a publié plus de 3 000 paquets (morceaux) de ce type, chacun avec des centaines de dépendances, une seule commande « npm install everything » commencera à résoudre ce que l'on appelle les dépendances transitives et finira par télécharger des millions de paquets.
"everything" était accompagné d'un fichier demandant de ne pas l'installer
L'incident a déclenché des réponses de la part des développeurs incapables de dépublier leurs packages obsolètes ou expérimentaux, ainsi que des critiques de la part de certains qui considéraient cette cascade comme un abus du système NPM open source.
Les développeurs derrière "everything" ont déclaré qu’ils n’avaient pas anticipé ces conséquences et ont contacté NPM et GitHub pour résoudre le problème. Ironiquement, l’équipe n’a pas pu dépublier "everything" elle-même en raison d’un cercle de dépendances qui rendait essentiellement le package dépendant de lui-même.
« Nous avons juste pensé que ce serait drôle », a écrit Evan Boehs, un contributeur à "everything", en réponse à la question d'un autre utilisateur de GitHub sur l'objectif du projet. « Nous ne savions pas que tout cela allait arriver ».
Le package "everything" était accompagné d'un fichier « README » indiquant « S'il vous plaît, n'installez pas réellement ceci… ». Il comprenait également une image mème de Gary Oldman du film « Léon », représentant une scène dans laquelle le personnage d'Oldman crie de façon dramatique le mot « everyone » (tout le monde).
La section « à propos » du référentiel "everything" comprend également un lien vers le site Web « everything.npm.lol », qui affichait une animation représentant de nombreux packages en cours d'installation, suivie d'un mème du jeu vidéo « The Elder Scrolls V : Skyrim ».
Malgré l'avertissement de ne pas installer le package, le site de registre NPM indique que « everything » a été téléchargé des centaines de fois
Jossef Harush, responsable du groupe d'ingénierie de sécurité de la chaîne d'approvisionnement chez Checkmarx, a déclaré dans un billet de blog que l'installation de "everything" entraînerait probablement un déni de service (DoS). Harush qualifie également le projet de « campagne de trolls ».
Les inconvénients de ces trolls
Imaginez que vous ayez fait une expérience, publié un package sur NPM et que vous souhaitiez maintenant supprimer votre package NPM. Vous ne pouvez pas le faire si d’autres packages l’utilisent. Le problème est que, puisque "everything" repose sur chaque package (y compris le vôtre), votre package reste bloqué et un package inconnu vous empêche de le supprimer.
Une tentative de suppression des packages
Il ne semble pas que PatrickJS ait réalisé le mal de tête que son troll causerait à certains utilisateurs. Deux jours après la publication des packages de farces, il a créé un problème et a déclaré qu'il ne pouvait pas supprimer les packages car le mécanisme NPM empêche la suppression des packages publiés une fois qu'ils sont utilisés par d'autres projets et appelle à l'aide de l'équipe de support NPM.
En somme
Cet acte de méfait numérique de PatrickJS fait écho à des incidents passés, mettant en évidence les défis persistants dans la gestion des packages et les effets en cascade des dépendances au sein de l'écosystème NPM. La situation souligne les conséquences comiques mais graves de telles farces dans la communauté des développeurs.
Imaginez que vous ayez fait une expérience, publié un package sur NPM et que vous souhaitiez maintenant supprimer votre package NPM. Vous ne pouvez pas le faire si d’autres packages l’utilisent. Le problème est que, puisque "everything" repose sur chaque package (y compris le vôtre), votre package reste bloqué et un package inconnu vous empêche de le supprimer.
Une tentative de suppression des packages
Il ne semble pas que PatrickJS ait réalisé le mal de tête que son troll causerait à certains utilisateurs. Deux jours après la publication des packages de farces, il a créé un problème et a déclaré qu'il ne pouvait pas supprimer les packages car le mécanisme NPM empêche la suppression des packages publiés une fois qu'ils sont utilisés par d'autres projets et appelle à l'aide de l'équipe de support NPM.
En somme
Cet acte de méfait numérique de PatrickJS fait écho à des incidents passés, mettant en évidence les défis persistants dans la gestion des packages et les effets en cascade des dépendances au sein de l'écosystème NPM. La situation souligne les conséquences comiques mais graves de telles farces dans la communauté des développeurs.
Plus de 2 millions de packages NPM pris dans « l’enfer des dépendances »
L’effet radical de "everything" sur l’ensemble du registre NPM révèle des failles dans le système open source NPM, affirme le contributeur PatrickJS sur GitHub, qui répond au pseudonyme gdi2290 sur le site NPM. PatrickJS, qui est à l'origine de cette farce, s'est excusé pour « toutes les difficultés causées par ce package » et a contacté les administrateurs de npm pour remédier au problème.
« Pour être clair, il s'agit d'un cas limite dans la politique de non-publication de NPM qui ne tient pas compte de '*' », a écrit PatrickJS sur GitHub, faisant référence au symbole étoile qui indique la dépendance d'un package sur toutes les versions d'un autre package. PatrickJS a suggéré que GitHub devrait permettre aux développeurs de dépublier un package si ses dépendances s'appuient sur des « versions étoiles », ou de désactiver complètement cette utilisation de « * ».
Voici une capture d'écran de la discussion GitHub désormais supprimée ci-dessous :
« Une autre chose à noter en discutant de ce fiasco, nous avons considéré que cela aurait pu être exploité pour des raisons bien plus malveillantes », a déclaré Boehs, un autre contributeur. « Disons que si quelqu'un télécharge accidentellement des informations sensibles, un acteur malveillant pourrait créer des packages pour les conserver. C’est bien qu’il ait été capturé de cette manière plutôt qu’après avoir été exploité dans la nature ».
Certains autres développeurs n’étaient pas convaincus, exprimant leur frustration et leur désapprobation sur le forum des problèmes du référentiel "everything".
Un utilisateur, Matt Lucock, a fustigé le groupe pour « négligence imprudente » et pour avoir blâmé NPM pour les retombées de son projet.
« Vous vous êtes trompés en croyant que le problème n'est pas que vous avez abusé du registre, mais que les règles de non-publication de npm ne résistent pas à quelqu'un qui abuse du registre de cette manière », a écrit Lucock, ajoutant que les règles de non-publication sont nécessaires pour « protéger l’intégrité du registre ».
Nicolas Ventura, ing...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.