Retour sur l’affaire Left-Pad, 8 ans après (2024)

• L’affaire left-pad reste, huit ans plus tard, un cas emblématique autour des dépendances open source et du pouvoir de gestion des packages, et Azer Koçulu revient sur sa décision de l’époque
• La décision de rendre ses packages privés n’était pas motivée par la colère ou l’avidité, mais par une introspection, le contexte essentiel étant que NPM avait enfreint ses propres règles
• Sous la pression de Kik Messenger, il estime que NPM a fait passer d’autres valeurs avant la communauté open source, ce qui a conduit à la suppression de tous ses packages
• La suppression visait plus de 350 packages, mais il était difficile d’en mesurer l’impact réel à partir des seules statistiques d’usage et de l’activité GitHub
• Environ 10 minutes après l’exécution du script NPM, plusieurs projets dont React ont été cassés, puis le module a été restauré en quelques heures et la situation est revenue à la normale

---

Le jugement porté au moment de l’affaire left-pad

• 8 ans se sont écoulés depuis l’affaire left-pad, et Azer Koçulu estimait qu’il valait mieux éviter ce sujet afin de se concentrer sur son travail réel
• Il a pris la décision de rendre ses packages privés en 2016, durant une période où il passait la plupart de ses week-ends à camper dans des lieux isolés sans réseau
  • Il explique qu’il s’agissait d’un choix né non de la logique, de la colère ou de l’avidité, mais d’une introspection au contact de la nature et d’une décision venue du cœur
• Le principe qui guidait son jugement était simple
  • Si NPM supprimait l’un de ses packages en violant ses propres règles, alors il devait, selon le même critère, supprimer aussi tous ses autres packages
• Il considère que l’esprit des règles est plus important que les règles elles-mêmes
  • Il reconnaît que, dans d’autres contextes, il peut exister de bonnes raisons de demander la suppression d’un package sans l’autorisation de son propriétaire
  • Mais dans ce cas précis, il estime que Kik Messenger a exercé son pouvoir sur la communauté open source fondée sur NPM avec des menaces telles que “we’ll bang on your door” et “take down your accounts”
• Réduire l’affaire à « une personne en colère qui proteste contre des intérêts d’entreprise » fait passer à côté des dates des e-mails et de la chronologie, de la situation où il tenait sous pression, ainsi que de la manière dont une décision évolue dans un autre état de conscience

Processus de suppression et impact

• Du point de vue de NPM, il estime que la suppression n’était ni soudaine ni imprévisible
  • Il avait d’abord demandé à NPM de supprimer ses modules et attendu une réponse
  • Comme il n’avait fixé aucune date limite, il considère que NPM avait l’occasion d’ajuster son API et ses outils pour rendre la transition plus fluide
  • À la place, NPM lui a fourni un script permettant de supprimer tous les packages d’un coup
• La majeure partie de son travail open source suivait la philosophie Unix, avec de petits packages ne faisant qu’une seule chose à la fois
  • Il y avait plus de 350 packages, tous optimisés et testés
  • En apparence, ils semblaient peu populaires, NPM n’affichait pas les statistiques d’usage et 90 % d’entre eux n’avaient presque aucune activité sur GitHub
  • Du point de vue d’un utilisateur ordinaire, il était difficile de savoir quel impact aurait leur passage en privé
• Après avoir exécuté le script fourni par NPM, il s’est absenté quelques minutes, puis environ 10 minutes plus tard, un ami lui a signalé que cela faisait le buzz sur Twitter
  • L’un des plus de 350 packages a cassé React et plusieurs autres projets
  • Il a ensuite rédigé un court billet de blog, transmis son travail open source et transféré la propriété de ses dépôts GitHub à des volontaires
  • En quelques heures, le module a été restauré et la situation est revenue à la normale
• Quelques mois plus tard, il a quitté son emploi et a définitivement quitté les États-Unis, passant un an au Morocco, en Jordan, en Türkiye et en Indonesia
• left-pad a été pour lui un moment comparable à une mort et une renaissance : une part de lui profondément attachée à l’open source a disparu et quelque chose de nouveau a pris sa place ; aujourd’hui, il est aussi passionné par la création et la gestion d’entreprises que par la programmation

[ndrgrd]

C’était un incident aux conséquences importantes, mais même sans lire le texte de l’auteur du package, je pense que la faute vient moins de lui que des entreprises et des systèmes impliqués.

[GN⁺]

Commentaires sur Hacker News

• J’ai eu du mal à bien comprendre la moitié du billet de blog, qui m’a semblé manquer de contexte, mais j’ai apprécié que la personne directement impliquée dans left-pad ait écrit une analyse rétrospective
  Cela dit, l’idée selon laquelle « NPM aurait dû vérifier si mon module était largement utilisé, puis réfléchir à un moyen de le dépublier sans rien casser » semble étrange. Que la fonctionnalité de dépublication de NPM ait été mal conçue, c’est vrai, mais si cela signifie qu’on s’attendait à ce qu’un employé de l’entreprise examine manuellement chaque cas à chaque dépublication, cela ne paraît pas raisonnable. La société NPM ne se rapproche pas tant d’un acteur qui curate le registre que d’un hébergeur de service public
  Malgré cela, il est difficile d’en vouloir fortement à l’auteur. Même s’il n’avait pas déclenché l’incident left-pad, quelqu’un d’autre l’aurait probablement fait peu après, et NPM a corrigé le problème avec une meilleure politique de dépublication : https://docs.npmjs.com/policies/unpublish#packages-published...

  • Le 18 mars 2016, Isaac Z. Schlueter, CEO de npm, Inc., a envoyé un mail à la fois à Kik Interactive et à Koçulu pour dire qu’il allait transférer manuellement à Kik Interactive la propriété du package kik ; lorsque Koçulu a exprimé sa déception et annoncé qu’il quitterait la plateforme, Schlueter lui a fourni une commande pour supprimer les 273 modules qu’il avait enregistrés
    Koçulu n’a fait qu’exécuter cette commande le 22 mars 2016 pour retirer tous les packages qu’il avait publiés, et plus tard NPM a rejeté la faute de son propre échec sur l’auteur
  • Pour le contexte, voir https://en.wikipedia.org/wiki/Npm_left-pad_incident
  • En pratique, NPM curate bien le registre, principalement en signalant les vulnérabilités aux utilisateurs et en supprimant les packages malveillants
  • À l’époque où j’utilisais Sourceforge, il fallait d’abord obtenir une autorisation pour supprimer un projet, et c’est après left-pad que j’ai compris pourquoi

• En tant que personne qui évite JavaScript et son écosystème comme on éviterait la peste Visual Basic du XXIe siècle, l’aspect le plus intéressant de cette histoire est que Koçulu a pris ses distances avec le milieu de la tech pendant un temps, a fait de superbes randonnées, du camping et de l’exploration de sentiers, et qu’huit ans plus tard il ressent encore le besoin de se justifier
  La tech ressemble à une muse capricieuse. Nous, les nerds, nous nous y accrochons et nous nous rabotons au service qu’on lui rend, mais elle finit toujours par nous rappeler à sa lumière
  Comme quelqu’un qui était là lors du Morris worm et qui a passé plusieurs semaines à en atténuer les effets, je pense qu’il y a un problème fondamental dans notre capacité à créer des technologies qui changent le monde avec les outils actuels. Moins nous faisons d’efforts pour comprendre les échecs organisationnels et éthiques de la tech, moins celle-ci est capable de produire un changement fécond dans les domaines où elle est appliquée
  Moi aussi, j’ai l’impression qu’après environ un mois, et quelques centaines d’échecs de compilation, je serai bon pour un congé sabbatique, et je me demande à quoi ressemblera, dans quelques années, l’espace technologique que j’aurai façonné à une autre échelle et dans un autre contexte pour répondre à mes besoins
  Il faudrait peut-être que le fait, pour les technologues, de prendre plus souvent et plus sérieusement un congé sabbatique devienne une certaine norme. Cela nous donnerait le contexte nécessaire pour comprendre les dilemmes éthiques qui pèsent sur nos capacités techniques

• Détail mineur, mais la phrase « la plupart des travaux open source suivaient la philosophie Unix, et les packages ne faisaient qu’une seule chose à la fois » est ambiguë
  L’exemple le plus obvious, c’est que peu de gens considèrent que libc va à l’encontre de la philosophie Unix. Les débats portent en général sur le fait qu’une commande ou qu’un démon en fasse trop, ou ne soit pas assez composable. L’exemple récent le plus connu est systemd

  • Le tumulte autour de left-pad a plutôt montré que le morcellement des packages NPM était devenu si extrême qu’on avait atteint un point où la surcharge de gestion des packages dépassait les bénéfices de leur simplicité
  • Il y a tout de même pas mal de gens qui pensent que libc va à l’encontre de la philosophie Unix. Si vous voulez, je peux vous le dire tout de suite
    Une libc moderne va assez largement à l’encontre de la philosophie Unix. La libc Unix traditionnelle était bien plus simple et beaucoup de fonctions n’étaient que des appels système. Aujourd’hui, une partie de ce qu’on trouve dans libc était autrefois séparée dans des bibliothèques distinctes comme libm, et il n’y avait pas du tout des choses comme NSS ou des frameworks complexes de résolution DNS
  • À l’opposé de « faire une seule chose », il y a aussi l’exigence de faire cette chose entièrement
  • La philosophie Unix est peut-être inutile, voire nuisible. Comme « une seule chose » n’est pas bien défini, cela n’apporte rien de concret et ne produit en pratique que des débats
    On pourrait dire qu’Eclipse fait « une seule chose », à savoir être une plateforme d’IDE, mais je ne pense pas que ce soit ce que les développeurs Unix voulaient dire. De même, ils ne voulaient probablement pas dire qu’il fallait créer une bibliothèque qui ne contienne qu’une fonction de 11 lignes
    Le vrai conseil devrait plutôt être : « un programme ou une bibliothèque ne doit ni en faire trop, ni en faire trop peu ». Déterminer ce qui est trop ou pas assez demande au fond, comme beaucoup de recommandations en programmation, du jugement et de l’expérience
  • La philosophie Unix est une philosophie qui explique comment obtenir un environnement de programmation interactif puissant sur des mini-ordinateurs 16 bits où la taille maximale du segment texte était de 64 KiB. Aujourd’hui, la libc que vous utilisez sur votre téléphone fait 1 MiB, soit 16 fois plus ; au moins 90 % de libc va donc à l’encontre de la philosophie Unix
    Après avoir lu le Lions book ou APUE, puis de l’autre côté les manuels de pthreads ou la spécification ANSI C de setlocale(), il ne me semble pas possible d’en conclure que les deux relèvent de la même philosophie. Ce serait du niveau de considérer Ayn Rand et Épicure comme représentatifs d’une même philosophie, ce qui reviendrait à montrer qu’on ne s’est jamais sérieusement engagé avec l’une ni avec l’autre.

• Ce qui ressort le plus fortement de cet incident, c’est que la communauté JavaScript dépendait beaucoup trop des dépendances.
  Il s’agissait seulement de retirer de la publication un paquet de 11 lignes de code https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou..., et je ne comprends pas pourquoi cela a suscité autant de critiques. Le texte dit aussi qu’il n’avait pas pleinement compris à quel point cela provoquerait une énorme frustration.
  NPM n’avait pas de statistiques d’usage et il n’y avait presque aucune activité sur GitHub, donc du point de vue des utilisateurs, il était impossible de connaître l’impact du retrait du paquet. À la racine, le problème serait moins le fait qu’akoculu ait retiré le paquet que la surabondance de dépendances, la politique de npm et les systèmes de build qui ne mettent pas le code en cache ou ne l’intègrent pas en vendorisation.

• Azer Koçulu n’a jamais été une catastrophe pour l’écosystème NPM. Personne n’a forcé qui que ce soit à utiliser left-pad, et s’il s’est retrouvé dans autant de projets, c’est à cause de dépendances transitives désordonnées.
  En revanche, Jon Schlinkert semble créer ce genre de micro-librairies délibérément, et même en les ajoutant à un projet légitime et largement utilisé comme handlebars-helpers, il ne semble avoir aucune intention de les intégrer réellement aux projets qui les utilisent. Si vous voulez vous faire piéger, utilisez handlebars-helpers ; sinon, arrêtez simplement d’utiliser cette bibliothèque.

  • En plus, il n’a fait qu’exécuter le script fourni directement par NPM. La situation des micro-paquets était certes absurde, mais Azer Koçulu n’a rien fait de mal.
    Le problème, c’est que NPM s’est approprié son paquet de force et a fourni un script dont il était évident qu’il était dangereux à exécuter. Le simple fait qu’Azer Koçulu ait été blâmé est ridicule.
    Jon Schlinkert donne l’image du parfait personnage nuisible adepte du marketing, et personnellement, je pense qu’il devrait être banni de NPM et de GitHub.

• L’historique des versions du paquet kik est étrange. Il a été remplacé il y a 9 ans par un paquet d’occupation à but de sécurité : https://www.npmjs.com/package/kik?activeTab=versions

  • La plus grande ironie, c’est que le paquet kik que Kik voulait si désespérément n’était au final pratiquement rien du tout.
    Kik apparaît comme une entreprise négligente et assez sordide. Il y a aussi eu des controverses liées aux cryptomonnaies, mais ce dont je me souviens surtout, c’est que la pornographie, en particulier les contenus d’exploitation sexuelle d’enfants, proliférait sur Kik ; c’est aussi abordé dans cet épisode de Darknet Diaries : https://darknetdiaries.com/episode/93/
    Sous cet angle, le fait qu’Azer Koçulu les ait envoyés promener est plutôt jubilatoire.
  • Au final, on dirait que toute cette affaire a eu lieu pour du vent.

• Le simple fait que left-pad ait été un paquet est assez comique. Cela fait réfléchir au nombre d’octets qui ont dû transiter via des CDN, des proxys, des pipelines de build, etc., juste pour utiliser une toute petite fonction utilitaire.
  Réutiliser des solutions existantes, c’est très bien, mais quand on a besoin de padding de chaîne, j’ai du mal à comprendre l’idée de se dire : « il doit bien y avoir un paquet pour ça ».

  • Une partie du débat à l’époque allait dans le sens que cet incident avait été un signal d’alarme salutaire pour les développeurs web qui s’appuyaient sans fin sur des micro-paquets comme left-pad.
    Il existait aussi une culture consistant à publier des paquets pour gagner en popularité et récolter des GitHub stars, et certains développeurs insistaient pour dire qu’implémenter soi-même quelque chose qu’on pouvait installer via NPM revenait à « réinventer la roue ». Même aujourd’hui, je travaille encore souvent avec des développeurs qui préfèrent les micro-paquets, même pour des fonctionnalités simples ; pour eux, cela signifie « moins de maintenance ».
  • L’implémentation d’origine du paquet https://en.wikipedia.org/wiki/Npm_left-pad_incident semble elle aussi avoir eu un comportement en O(n²) plutôt que le O(n) attendu.
  • Je me demande si la différence qualitative entre réutiliser une fonction utilitaire déjà écrite par quelqu’un dans un projet et réutiliser un paquet déjà publié par quelqu’un dans l’écosystème est vraiment si grande.
    Bien sûr, ce n’est pas exactement la même chose, mais si les outils sont suffisamment mûrs, cela ne me paraît pas si absurde de vouloir traiter les deux de façon similaire.
  • J’ai l’impression que c’est un peu pareil avec l’IA aujourd’hui. Combien de prompts pourraient être résolus par une simple recherche web ?
    Ce n’est guère plus qu’un copier-coller avec quelques étapes supplémentaires.
  • C’est l’ostentation maximale de la réutilisation de code, et le copier-coller, c’est pour les perdants.

• Il y a ce passage : « Du côté de NPM, j’ai vu une attitude générale de mépris envers les développeurs, qui a conduit à une série de décisions irrationnelles et a fini par me faire porter tous les coûts », et NPM ne semble pas avoir vraiment retenu la leçon même après cet incident.

• Au fond, c’est une bonne chose que cet incident se soit produit. Le name squatting est un vrai problème et, en cas d’ambiguïté, il faut choisir l’option qui surprend le moins les utilisateurs.
  L’absence de statistiques d’usage était aussi un gros problème, tout comme le fait qu’on puisse simplement retirer un paquet de la publication. Que l’infrastructure dépende d’un bout de code insignifiant de 10 lignes écrit par un individu aux opinions tranchées était un vrai problème à l’époque, et cela l’est encore aujourd’hui. Dans cette situation, il est difficile de dire que quelqu’un en particulier est réellement responsable ; personne ne doit rien à personne, mais tout le monde peut en tirer des leçons.

• Du point de vue de quelqu’un qui maintient quelques-uns des 10 principaux paquets npm, ce texte est totalement pertinent
  À un certain moment, NPM a cessé de coopérer avec la communauté. Le rachat par Microsoft n’a fait qu’acter cela, mais c’était évident bien avant
  Le mode de fonctionnement de npm présentait de nombreuses fissures, ils coopéraient mal avec la communauté comme avec l’équipe principale de Node, et leur poussée vers la viabilité commerciale paraissait très irritante et coercitive. Plusieurs membres de l’équipe avaient aussi une réputation assez rude
  Je suis aussi passé par les bureaux d’Oakland, et il y a eu des interactions assez intéressantes, pas spécialement positives, mais je vais m’arrêter là
  À l’époque, la faille liée à l’annulation publique était bien connue. Tout le monde accusait left-pad d’avoir cassé Internet, mais presque personne n’a demandé des comptes à npm, qui avait gravement mal géré toute l’affaire
  Si je me souviens bien, npm a restauré le paquet de force contre la volonté du mainteneur, ce qui, dans le meilleur des cas, montrait une déconnexion avec ceux qu’ils prétendaient servir, et dans le pire des cas paraissait même juridiquement douteux. Juste après, ils se sont aussi peu souciés des abus de la plateforme, il y a eu des choses comme le spam publicitaire de core.js, et ils ne coopéraient pas non plus correctement avec la communauté sur les standards, la compatibilité, etc.
  La sortie de npm@5 a été un désastre. L’introduction du fichier de verrouillage des paquets n’aurait pas pu être pire et, si ma mémoire est bonne, il y avait une pression pour le publier en phase avec la prochaine version majeure de Node.js. J’avais l’impression que l’équipe Node n’attendait pas que npm soit prêt, mais vu que npm était une entreprise à but lucratif, ou du moins agissait comme telle, c’était plutôt une bonne chose
  La réponse à la communauté pendant la période d’interminables bugs critiques, l’attitude consistant à faire honte à la communauté quand elle mettait la pression, et cette posture faussement pieuse étaient la preuve que npm n’était plus un représentant du logiciel libre et open source. Je ne me rappelle plus si left-pad est arrivé avant ou après, mais dans mon esprit cela fait partie d’un même long déclin de l’écosystème
  Aujourd’hui, les paquets npm sont devenus le mème des petits paquets qui font des tâches triviales, et tout le monde s’en moque. Avec le recul, ce n’était peut-être pas l’idéal. Mais le contexte compte. npm a été le premier gestionnaire de paquets vraiment très accessible pour une technologie nouvelle et en plein essor, presque entièrement géré par la communauté, avec un bon système de recherche et une intégration étroite à l’esprit de « social coding » de GitHub
  C’était au tout début de Node, à une époque où même ES5 n’existait pas encore, quand on écrivait avec var et prototype. Il n’y avait pas encore vraiment de bonnes pratiques JavaScript, Joyent n’avait pas encore transmis Node.js à la communauté, et c’était aussi avant le fork Io.js et avant la sortie de la longue stagnation de Node 0.10/0.12
  Personne ne savait quelle était la meilleure manière de faire
  Je comprends totalement l’auteur. Du point de vue de la sécurité, je suis vraiment reconnaissant que left-pad soit arrivé. Même si ce n’était pas l’intention de l’auteur, cela a montré très clairement aux gens quels risques apparaissent quand on dépend d’intérêts d’entreprise séparés de la communauté qu’ils prétendent servir. Cela a lancé beaucoup de discussions sur la sécurité de la chaîne d’approvisionnement, la redondance, etc., et à long terme cela a un peu amélioré le secteur

  • Ce n’était pas non plus le premier gestionnaire de paquets pour un langage de programmation, et beaucoup de gens avaient déjà souligné qu’avoir des paquets aussi petits était absurde
    npm, et JavaScript dans son ensemble, sont surtout victimes de leur popularité