Developpez.com

Le Club des Développeurs et IT Pro

Un développeur sabote ses propres bibliothèques open source, puis prétend qu'Aaron Swartz a été assassiné,

Tandis que des milliers d'applications qui s'en servent sont perturbées

Le 2022-01-11 09:18:00, par Stéphane le calme, Chroniqueur Actualités
Le développeur qui a saboté deux de ses propres bibliothèques de code open source, provoquant des perturbations pour des milliers d'applications qui les utilisaient, a un passé qui inclut l'adoption d'une théorie QAnon impliquant Aaron Swartz, le célèbre hacktiviste et programmeur qui s'est suicidé en 2013.

Marak Squires, l'auteur de deux bibliothèques JavaScript avec plus de 21 000 applications dépendantes et plus de 22 millions de téléchargements hebdomadaires, a mis à jour ses projets à la fin de la semaine dernière après qu'ils soient restés inchangés pendant plus d'un an. Les mises à jour contenaient du code pour produire une boucle infinie qui provoquait l'affichage du charabia des applications dépendantes, précédé des mots « Liberty Liberty Liberty ».

Squires n'a fourni aucune raison pour avoir agi de la sorte, mais un 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 États-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.

Un acte qui lui valait également l'accusation de "crime" ("felony" par la justice américaine.

Aaron Swartz refusait obstinément d’accepter ce terme, d'après son collègue Lawrence Lessig. Un refus qui, après 18 mois de négociations, allait donc déboucher sur un procès aux peines potentiellement très sévères.

En réaction à sa mort, plusieurs professeurs du MIT ont décidé d’honorer son combat – qu’ils soutiennent – en mettant en ligne des PDF de leurs travaux pour lutter contre le copyright sur les articles universitaires. En plus de ces professeurs, le MIT a également – officiellement et en tant qu’institution – décidé de mener une enquête interne pour déterminer comment l’école de Boston avait agi, dans le détail, depuis le début de l’affaire des « vols » de documents. Et si ses décisions n’avaient pas été disproportionnées.

En même temps qu'il incluait la référence de Swartz dans le fichier Lisez Moi, Squires a également tweeté ces mêmes mots et a inclus un lien vers un fil de discussion affirmant que Swartz a été assassiné après avoir découvert de la pornographie pédopornographique sur les serveurs du MIT. Ce message désormais supprimé (mais disponible sur Web Archive - voir source), inclus dans le fil, indiquait :

« Non, ce n'est pas Aaron Swartz qui devrait être jugé, mais cette haute institution d'apprentissage salarié, le MIT, qui est responsable des crimes odieux qui ont conduit à sa mort. Les risques pris par Swartz, qui ont ainsi menacé le MIT, ne peuvent être compris qu'à travers la question de la pornographie juvénile orchestrée et produite par ses professeurs acclamés et distribuée à leurs riches et puissants sponsors. Les cyberproxénètes du MIT s'adressent à une clientèle qui comprend le plus haut échelon du département d'État, de grandes entreprises, des agences de renseignement, des militaires et la Maison-Blanche.

Chaque élément de l'affaire Swartz indique qu'il est mort dans une tentative héroïque d'exposer la perversion qui a corrompu les cœurs et les esprits de l'élite mondiale, un vice odieux et souvent meurtrier qui traumatise les enfants innocents et menace chaque famille sur cette planète.

Cette exposition des faits est un chemin tortueux qui mène des halls sacrés du lierre à Boston à la périphérie de Phnom Penh, où un professeur de renommée mondiale a organisé des services sexuels pour mineurs pour des dignitaires en visite et a envoyé de la pornographie juvénile cryptée par satellite à des bases de données illicites sur le campus du MIT.

Nicholas Negroponte, tu n'as plus d'endroit où te cacher en Asie du Sud-Est ou en Afrique, plus maintenant. Vous êtes sous surveillance et serez traqué sans relâche, non seulement pour pédopornographie et proxénétisme, mais désormais en tant que complice de meurtre. Votre seule issue est de retourner les fichiers vidéo avec la liste complète des noms, et vous feriez mieux de le faire le plus tôt possible, car les puissants pédophiles de cette liste vont vous faire taire pour couvrir leurs propres traces ».

Il existe également des preuves que Squires a peut-être été accusé il y a deux ans de mise en danger imprudente après avoir prétendument déclenché un incendie dans son appartement du Queens, à New York. Selon des articles de presse, un homme alors âgé de 37 ans, Marak Squires, a été arrêté après avoir été emmené à l'hôpital après que les autorités l'auraient observé agir de manière erratique alors qu'ils répondaient à l'incendie.

Les articles disaient que Squires était un développeur de logiciels et un des premiers investisseurs en bitcoins. Un mois après l'incendie, Squires a rapporté sur Twitter avoir « perdu toutes mes affaires dans un incendie d'appartement » et a demandé un soutien financier.


Le sabotage des bibliothèques soulève des inquiétudes quant à la sécurité de la chaîne d'approvisionnement logicielle qui est cruciale pour un grand nombre d'organisations, y compris les entreprises Fortune 500. Les deux bibliothèques sabotées, Faker.js et Colors.js, ont créé des problèmes pour les personnes utilisant le kit de développement cloud d'Amazon. Les grandes entreprises, disent les critiques depuis longtemps, profitent des écosystèmes open source sans rémunérer adéquatement les développeurs pour leur temps. À leur tour, les développeurs responsables du logiciel sont injustement mis à rude épreuve.

En effet, Squires a déclaré en 2020 qu'il ne soutiendrait plus les grandes entreprises avec un travail qu'il effectue gratuitement. « Profitez de cette occasion pour m'envoyer un contrat annuel à six chiffres ou forkez le projet et demandez à quelqu'un d'autre de travailler dessus », a-t-il écrit.

La capacité d'un seul développeur à mettre un frein à une base d'applications aussi vaste met en évidence une faiblesse fondamentale de la structure actuelle des logiciels libres et open source. Ajoutez à cela les ravages causés par des vulnérabilités de sécurité négligées dans les applications open source largement utilisées et vous avez une recette pour un désastre potentiel.

Sources : Web Archive, Marak Squires (1, 2), fichier lisez-moi de faker.js
  Discussion forum
41 commentaires
  • Ça a déjà été dit dans la discussion précédente. C'est surtout l'écosystème JavaScript / Node.js qui est bancal et en constante dette technique.

    Développer des applis dans cet environnement, c'est faire du jetable. Si elle ne sont pas maintenues pendant plus de 6 mois, il y a des chances non-négligeables qu'elles ne se lancent plus, parcen qu'elles utilisent des fonctions dépréciés, parce qu'une ou plusieurs dépendances ne sont plus mises à jour, etc ...

    Ce développeur aigri vient d'en faire la démonstration implacable, bien malgré lui il est vrai.

    A contrario, j'ai des projets Fortran dont le code n'a pas été mis à jour depuis 25 ans, et qui pourtant compile sans erreur.
  • Waikiki
    Membre averti
    Envoyé par Jeff_67
    Ça a déjà été dit dans la discussion précédente. C'est surtout l'écosystème JavaScript / Node.js qui est bancal et en constante dette technique.

    Développer des applis dans cet environnement, c'est faire du jetable. Si elle ne sont pas maintenues pendant plus de 6 mois, il y a des chances non-négligeables qu'elles ne se lancent plus, parcen qu'elles utilisent des fonctions dépréciés, parce qu'une ou plusieurs dépendances ne sont plus mises à jour, etc ...

    Ce développeur aigri vient d'en faire la démonstration implacable, bien malgré lui il est vrai.

    A contrario, j'ai des projets Fortran dont le code n'a pas été mis à jour depuis 25 ans, et qui pourtant compile sans erreur.
    Le problème vient surtout de besoin de mise à jour constante que certains devs ont.

    Hormis si la mise à jour apporte des changements de sécurité, quel est l'intérêt de courir après si celle-ci ne vous apporte rien ?

    On a l'impression de voir certaines utilisateurs de Linux qui refresh la page kernel.org 40 fois par jour pour pas louper la dernière version au risque de se retrouver avec bugs à la pelle.
  • grunk
    Modérateur
    Par exemple, Angelina Fabbro, directrice de l'ingénierie chez Splice, a déclaré 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 eu autant d'applis que ca impactées en prod ? Si c'est le cas c'est effectivement inquiétant. Ca veux dire que c'est déployé avec 0 test.

    Par contre sur des projets js d'envergure , bien malin celui qui est capable de maitriser son arbre de dépendances à 100% . Sur le premier niveau oui évidemment , ensuite ca devient très vite très compliqué. C'est le revers de la médaille d'avoir une gestionnaire de dépendances très efficace malheureusement.
  • cd090580
    Membre averti
    C'était son projet et sa bibliothèque.
    Il est encore libre de faire ce qu'il veut avec et tout supprimer si cela lui chante.....
  • jpouly
    Membre confirmé
    Envoyé par Stéphane le calme

    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 :
    C'est le problème d'utiliser trop de librairies dans un projet. Libre ou Payante d'ailleurs. Au bout de quelques années c'est un vrai calvaire à maintenir.
    Mieux vaut se contenter des framework de bases, même si cela limite les choses et ne simplifie pas le travail. Mais au moins on évite les déboires
    Après, faut aussi avoir du temps pour le faire.

    Envoyé par Stéphane le calme

    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.
    J'oserais faire le parallèle avec log4J. Avoir besoins de toute une usine à gaz pour tracer l'exécution du code dans un fichier, c'est un peu trop.
    Une simple écriture dans un fichier est beaucoup plus simple. Mais moins paramétrable, c'est sure.

    Envoyé par Stéphane le calme
    J'aimerais que les gens commencent à discuter de ces choses
    Il est surtout temps que les développeurs arrêtent de faire de mise à jour toutes les deux secondes et testent leurs logiciels avant de les diffuser. De VRAI tests.
    Pas des tests unitaires à la C qui ne sert à rien, mais de vrais tests fonctionnelles. La aussi, ça prend du temps, je l'accorde. Mais c'est ça faire de la qualité.

    Envoyé par Stéphane le calme
    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.
    Petite anecdote ; je recherchais un logiciel ou un bout de code pour voir les différents droits d'accès sur une collection de projet TFS.
    Finalement je trouve un projet sur GIT qui semblait correspondre.
    Ne voulant pas tout prendre, je repère dans le code ce qui m’intéresse et le copie dans un projet vierge sous VS.
    Malheureusement le projet GIT utilisait une classe externe pour écrire du csv.
    Après quelques recherches, je retrouve le package de cette fameuse classe. Et la, je me rend compte que c'est tout un ensemble de merdiers (sûrement très bien ) avec tout plein d'abstraction et de codes de réflexion.
    Au final j'ai récrit la classe pour écrire le fichier csv. Et ça m'a pris moins de temps que j'avais mis à retrouver le package csv.

    En conclusion, je suis assez d'accord avec Armin Ronacher. La plus part des développeurs montent des logiciels sur des bases branlantes, par manque de temps ou tout simplement fainéantise.

    Il est temps que cela change et qu'on arrête d'utiliser ces gestionnaires de packages.
  • redcurve
    Membre extrêmement actif
    Envoyé par cd090580
    C'était son projet et sa bibliothèque.
    Il est encore libre de faire ce qu'il veut avec et tout supprimer si cela lui chante.....
    Tout à fait ça reste SA propriété intéllectuelle
  • kain_tn
    Expert éminent
    Envoyé par Stéphane le calme

    « 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 [...] »
    Aaaaah, le complotisme. Le truc pour décrédibiliser n'importe quels propos. Le gars est encore libre de penser ce qu'il veut, et peut-être que son affirmation sur la mort de Aaron Swartz n'est pas à prendre au sens littéral (je ne suis pas dans sa tête).

    Envoyé par jpouly
    C'est le problème d'utiliser trop de librairies dans un projet. Libre ou Payante d'ailleurs. Au bout de quelques années c'est un vrai calvaire à maintenir.
    Mieux vaut se contenter des framework de bases, même si cela limite les choses et ne simplifie pas le travail.
    Tout à fait. On ne devrait tirer des dépendances externes que lorsqu'elles sont nécessaires. Après, le problème qui se pose ici est celui des dépendances transitives.

    Envoyé par jpouly

    J'oserais faire le parallèle avec log4J. Avoir besoins de toute une usine à gaz pour tracer l'exécution du code dans un fichier, c'est un peu trop.
    Une simple écriture dans un fichier est beaucoup plus simple. Mais moins paramétrable, c'est sure.
    Ou alors, dans le cas de Log4J apprendre que SLF4J, une API de log compatible avec la plupart des frameworks de log Java (dont Log4J), est disponible depuis au moins 2006, et que c'est idiot d'avoir du code qui dépende d'implémentations plutôt que d'abstractions, surtout quand on sait que chaque projet/framework/serveur peut tirer son implémentation.

    Envoyé par jpouly

    Il est surtout temps que les développeurs arrêtent de faire de mise à jour toutes les deux secondes et testent leurs logiciels avant de les diffuser. De VRAI tests.
    Pas des tests unitaires à la C qui ne sert à rien, mais de vrais tests fonctionnelles. La aussi, ça prend du temps, je l'accorde. Mais c'est ça faire de la qualité.
    Là encore, ça dépend de la façon dont le projet est architecturé. C'est sûr que si on a un patchwork de CRUD ou de la SPA sans aucune gestion d'états, l'écriture et surtout la maintenance de tests automatisés devient très compliquée, ce qui laisse peu de temps pour automatiser des tests UI par exemple.

    Envoyé par jpouly

    Il est temps que cela change et qu'on arrête d'utiliser ces gestionnaires de packages.
    Eh bien ça dépend. Un gestionnaire de packages, ça permet de gérer les dépendances, y compris sur vos projets en interne, ce qui est formidable. Le problème c'est plutôt le patchwork de bibliothèques en dépendances directes/transitives, et là on en revient au point écrit plus haut, de n'embarquer les choses que quand elles sont nécessaires.

    Envoyé par cd090580
    C'était son projet et sa bibliothèque.
    Il est encore libre de faire ce qu'il veut avec et tout supprimer si cela lui chante.....
    Tout à fait. Mais visiblement Github n'est pas d'accord avec ça et se torche complètement avec la licence déclarée sur notre code.
    Une façon respectueuse de la licence aurait été de forker le projet, de le publier comme fork, et de demander à tous ceux qui ont automatiquement tiré la dernière version du paquet (mauvaise pratique) de remplacer leurs dépendances.
  • Demky
    Membre habitué
    Je ne comprends pas trop, n'avons nous pas eu droit la semaine dernière a une floppée d'article indiquant qu'il avait été débanni ?

    A la base, c'est son projet, il est donc sencé pouvoir en faire ce qu'il veut, je ne comprends pas pourquoi il est banni par github.
  • TJ1985
    Membre chevronné
    Pour voir ce que c'est, j'ai passé environ une journée à tenter d'installer scala, cette semaine. Je suis horrifié par la pile de dépendances, notamment à Java que ça nécessite. On dépend d'un EDI, forcément, vu la complexité de l'environnement, et le préféré est IntelliJ... Il semble très réputé chez les javaistes, mais quelle usine, aussi !
    Pourtant j'ai travaillé dans des environnements multiplateformes, gérant plusieurs architectures de processeurs et versions du système. Jamais vu un beusier pareil.
    Bref, plus je vois ces magnifiques outils, ce qu'ils permettent de produire comme daube, plus je me dis que l'informatique compilée à partir de langages adaptés à la tâche avait du bon. Et plus j'évite les machins et les sites qui les utilisent.
  • BicBac
    Futur Membre du Club
    Ce qui est terrible c'est qu'on associe open-source et gratuit.