Marak Squires, l'auteur de deux bibliothèques open source populaires que sont colors.js et faker.js, les a intentionnellement corrompu les deux bibliothèques. La bibliothèque colors a eu plus de 20 millions de téléchargements hebdomadaires uniquement sur npm et compte près de 19 000 projets qui en dépendent. Tandis que, faker a eu plus de 2,8 millions de téléchargements hebdomadaires sur npm et compte plus de 2 500 personnes à charge.Le développeur de ces deux bibliothèques a introduit un commit (une révision de fichier sur GitHub) dans colours.js qui ajoute un nouveau module de drapeau américain, ainsi que le déploiement de la version 6.6.6 de faker.js, déclenchant la même tournure destructrice des événements. Les versions sabotées amènent les applications à produire à l'infini des lettres et des symboles étranges, commençant par trois lignes de texte qui se lisent « LIBERTY LIBERTY LIBERTY ».
Plus curieusement encore, le fichier Lisez-moi de faker.js a également été remplacé par « Que s'est-il réellement passé avec Aaron Swartz ? » Swartz était un développeur de premier plan qui a aidé à établir Creative Commons, RSS et Reddit. En 2011, Swartz a été accusé d'avoir volé des documents de la base de données académique JSTOR dans le but de les rendre libres d'accès. Militant impliqué dans les grandes causes comme la neutralité du Net, il s’était opposé aux lois SOPA et PIPA (équivalentes de la Hadopi aux Etats-Unis). Aaron Swartz s’est suicidé en janvier 2013. Sujet aux épisodes dépressifs, il était sous le coup d’une procédure légale lourde. Il encourait pas moins de 4 millions de dollars d’amende et 30 ans de prison pour avoir cracké et dérobé 4 millions de documents académiques du MIT et du site Jstor. Un acte réalisé au nom du libre accès à la connaissance.
Dans l'un des messages du développeur sur GitHub datant de novembre 2020, il déclare qu'il ne veut plus faire de travail gratuit. « Avec tout mon respect, je ne vais plus soutenir les Fortune 500 (et d'autres entreprises de plus petite taille) avec mon travail gratuit », disait-il. « Saisissez cela comme une opportunité de m'envoyer un contrat annuel à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus. »
Malgré les ravages provoqués, le symbole du développeur open source modeste se dressant contre les grandes et riches entreprises qui profitaient de lui a énormément résonné dans les discussions sur les forums spécialisés. La réponse à ces actions a elle aussi provoqué un débat.
Il faut dire que suite à la corruption des bibliothèques, Microsoft a rapidement suspendu son accès GitHub et annulé les projets sur npm. Un porte-parole de GitHub a proposé cette déclaration aux actions prises par la structure : « GitHub s'engage à assurer la santé et la sécurité du registre npm. Nous avons supprimé les packages malveillants et suspendu le compte utilisateur conformément à la politique d'utilisation acceptable de npm concernant les logiciels malveillants, comme indiqué dans nos conditions Open Source ».
L'entreprise a également publié l'avis de sécurité suivant : « colors est une bibliothèque permettant d'inclure du texte coloré dans les consoles node.js. Entre le 07 et le 09 janvier 2022, les versions couleurs 1.4.1, 1.4.2 et 1.4.44-liberty-2 ont été publiées incluant du code malveillant qui a provoqué un déni de service en raison d'une boucle infinie. Les logiciels dépendant de ces versions ont connu l'impression de caractères aléatoires sur la console et une boucle infinie entraînant une consommation de ressources système non liée. Les utilisateurs de couleurs s'appuyant sur ces versions spécifiques doivent rétrograder vers la version 1.4.0 ».
Bien que cela puisse être évident pour certains (le développeur a introduit un commit avec du code malveillant et GitHub et npm ont fait ce qu'il fallait pour protéger ses utilisateurs), un débat a éclaté autour des droits d'un développeur à faire ce qu'il souhaite avec son code, quel que soit le nombre de projets et de dépendances qu'il peut avoir.
Par exemple, Angelina Fabbro, directrice de l'ingénierie chez Splice, a noté sur twitter :
« GitHub suspend le compte de quelqu'un pour avoir modifié son propre code dans un projet qu'il possède me fait bien plus peur que NPM qui annule un paquet. J'aime un peu ce que Marak a fait pour se faire entendre et protester.
« Si ces entreprises et leur infrastructure sont si fragiles qu'un ou deux packages qui changent ou disparaissent font des ravages, disons le, leur modèle de risque est nul (c'est en fait le cas de toutes les entreprises technologiques)
« Il y a une chose qui me fait sangloter ET rire… où était l'assurance qualité ? Vous mettez simplement à jour automatiquement les packages et n'exécutez pas de tests de régression avant de publier une nouvelle version de votre logiciel ? C'est gênant ».
Toute suspension semble déraisonnable si vous considérez que le code dans les dépôts appartient à son créateur/mainteneur. Oui, c'est open source en ce sens que vous pouvez le forker et y contribuer, mais cela signifie-t-il que GitHub puisse justifier de vous refuser le droit de modifier ou même de détruire votre propre code ? Y a-t-il une « procédure régulière » dans ce genre de décision ? Y a-t-il un droit d'appel ? GitHub agit en tant que juge, jury et bourreau dans ces affaires et bien que vous puissiez être d'accord avec son action actuelle, qu'en est-il lorsqu'il qu'il se trompe ?
Les autres problèmes soulevés par ces événements sont de savoir comment récompenser de manière adéquate les individus pour le travail qu'ils ont investi dans le logiciel open source qui sous-tend d'autres logiciels plus importants qui permettent aux méga-entreprises de réaliser d'énormes profits. Dans ce cas, ces bibliothèques JavaScript sont utilisées par le kit de développement cloud d'Amazon, qui fait partie d'AWS. Même si colors.js et faker.js bénéficient d'un parrainage qui vise à garantir que les communautés open source soient payées pour le travail qu'elles font, il existe un énorme décalage dans ce que les développeurs qui ont conçu et implémenté des packages populaires comme colors.js et faker. js reçoivent et leur valeur pour les entreprises qui réutilisent leur travail gratuitement.
Le développeur Shirego pour sa part indique : « Je pense, objectivement, qu'ils ne devraient pas faire cela. Même s'il s'agit de projets très importants, ce sont toujours vos projets et c'est finalement à vous de décider ce que vous en faites. GitHub et npm agissant sur les décisions de quelqu'un ne semblent pas cool ».
Brandon Weaver, pour sa part, estime que le débat sur la rémunération des contributeurs de logiciel open source mérite d'être lancé, mais n'approuve pas les méthodes de Marak Squires :
« Maintenant, beaucoup de gens dénoncent GitHub et NPM pour avoir fermé son compte et censuré, ainsi que son discours sur les mainteneurs d'OSS qui ont besoin d'être payés plus au lieu d'être exploités.
« Pour être clair, je suis d'accord avec le point sur OSS, mais je ne suis pas d'accord avec le porte-drapeau ».
Quoiqu'il en soit, le compte de Marak Squires a à nouveau été activé et il a écrit ceci :
« J'ai supprimé le bogue infini de zalgo avec colors v2.2.2 et j'attends des nouvelles du support Github pour récupérer mes droits de publication NPM.
« Aux membres vertueux de la 69e division des médecins des médias sociaux :
« Je vous remercie pour vos pensées et vos prières.
« Je peux vous assurer que je suis sain de corps et d'esprit. J'ai joint un certificat de l'établissement psychiatrique Reid, qui prouve sans l'ombre d'un doute que moi, Marak Squires, je n'ai pas de cerveau d'âne.
« Les membres de la 69e division des médecins des médias sociaux peuvent-ils fournir un document prouvant qu'ils n'ont pas de cerveau d'âne ? »
Risque de dépendance et financement
Armin Ronacher tire la sonnette d'alarme sur les dépendances à outrance, préférées à la place des implémentations internes :
« La bibliothèque colors émet effectivement des codes ANSI pour la colorisation. Une fonctionnalité utile à coup sûr, mais pas révolutionnaire. Je dirais que ce type de fonctionnalité est très souvent mis en œuvre directement au lieu d'en faire une dépendance. Par exemple, lorsque j'ai écrit click, j'ai délibérément décidé d'implémenter la coloration ANSI directement dans ma propre bibliothèque sans dépendre de quelque chose. Mon intuition est qu'il ne faudrait pas longtemps pour arracher et remplacer cette bibliothèque.
« Il y a quelques jours, le développeur derrière cette bibliothèque a décidé de publier une nouvelle version de la bibliothèque qui ne fait plus ce qu'elle annonçait sur la boîte. Comme il s'agissait d'une mise à jour mineure, plusieurs personnes se sont retrouvées avec cette version. Cependant, elles ne savaient même pas qu'elles dépendaient de "ce seul paquet", elles l'ont probablement ajouté parce que quelque chose d'autre dans leur chaîne de dépendance en avait besoin.
« Si vous êtes allé sur le référentiel GitHub de ce développeur, vous avez trouvé deux choses : du contenu complotiste dans le fichier readme du référentiel, mais aussi une justification de la raison pour laquelle sa bibliothèque ne faisait plus ce qu'elle était censée faire : le développeur n'était pas satisfait des entreprises du "fortune 500" qui utilisait son code gratuitement et a demandé un contrat à six chiffres ou de forker le projet et demander à quelqu'un d'autre de travailler dessus.
« J'aimerais que les gens commencent à discuter de ces choses, notamment du fait que npm (et d'autres gestionnaires de paquets) sont devenus des leviers incroyables. Quelqu'un qui a un forfait avec beaucoup de personnes à charge peut facilement éliminer cette partie de toute l'infrastructure numérique moderne. Daniel Stenberg de curl ne détient pas ce pouvoir (et ne veut probablement pas non plus)
« Le risque que pose une dépendance est élevé avec de petites dépendances plus couramment utilisées, par un seul développeur non vérifié, installées via un gestionnaire de packages comme npm, cargo, pypi ou similaire. Pourtant, quand quelque chose ne marche pas de ce côté, tout le monde s'en aperçoit immédiatement et les gens demandent rapidement des fonds. Pourtant, ce ne sont pas ces dépendances qui soutiennent réellement notre économie. Beaucoup de ces dépendances sont devenues fondamentales, non pas parce qu'elles résolvent un problème difficile, mais parce que nous avons collectivement commencé à adopter la paresse par-dessus tout le reste. Lorsque nous concentrons ensuite nos discussions sur le financement autour de ces types de dépendances, nous détournons implicitement l'attention des packages réellement importants ».
Sources : commentaire de Marak Squires sur GitHub, Armin Ronacher, Brandon Weaver, Shigero, Angelina Fabbro, avis de sécurité GitHub
Et vous ?
Êtes-vous d'accord avec le fait que GitHub ait fermé le compte du développeur qui a saboté ses propres bibliothèques ? Dans quelle mesure ? L'open source est-il vraiment libre si, en tant que propriétaires, nous ne sommes pas autorisés à disposer de nos œuvres comme nous le souhaitons ? Jusqu'à quel point ? Que pensez-vous des propos d'Armin Ronacher qui pense que « lorsque nous concentrons ensuite nos discussions sur le financement autour de ces types de dépendances, nous détournons implicitement l'attention des packages réellement importants » ? Que pensez-vous des propos d'Armin Ronacher qui pense que « Beaucoup de ces dépendances sont devenues fondamentales, non pas parce qu'elles résolvent un problème difficile, mais parce que nous avons collectivement commencé à adopter la paresse par-dessus tout le reste » ? 
Envoyé par Stéphane le calme
) avec tout plein d'abstraction et de codes de réflexion.
.