IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques
Certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code

Le , par Stéphane le calme

163PARTAGES

11  0 
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 » ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de grunk
Modérateur https://www.developpez.com
Le 17/01/2022 à 16:33
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.
6  0 
Avatar de cd090580
Membre actif https://www.developpez.com
Le 17/01/2022 à 19:19
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.....
6  0 
Avatar de jpouly
Membre confirmé https://www.developpez.com
Le 16/01/2022 à 23:54
Citation Envoyé par Stéphane le calme Voir le message

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.

Citation Envoyé par Stéphane le calme Voir le message

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.

Citation Envoyé par Stéphane le calme Voir le message
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é.

Citation Envoyé par Stéphane le calme Voir le message
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.
5  0 
Avatar de redcurve
Membre extrêmement actif https://www.developpez.com
Le 18/01/2022 à 7:15
Citation Envoyé par cd090580 Voir le message
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
4  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 17/01/2022 à 20:07
Citation Envoyé par Stéphane le calme Voir le message

« 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).

Citation Envoyé par jpouly Voir le message
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.

Citation Envoyé par jpouly Voir le message

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.

Citation Envoyé par jpouly Voir le message

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.

Citation Envoyé par jpouly Voir le message

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.

Citation Envoyé par cd090580 Voir le message
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.
3  0 
Avatar de Demky
Membre habitué https://www.developpez.com
Le 24/01/2022 à 10:27
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.
6  3 
Avatar de BicBac
Futur Membre du Club https://www.developpez.com
Le 17/01/2022 à 11:20
Ce qui est terrible c'est qu'on associe open-source et gratuit.
2  0 
Avatar de Fleur en plastique
Membre extrêmement actif https://www.developpez.com
Le 26/01/2022 à 14:56
Citation Envoyé par Demky Voir le message
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 ?
Oui parce que ce gros boulet de base, après avoir été débanni, a récidivé.

Du coup, il a été rebanni et je pense que cette fois-ci il devra passer sous le bureau pour espérer retrouver l'accès à son compte.

De plus, prétendre une "erreur de programmation" c'est vraiment du foutage de G. Il n'a même pas honte ? Il mérite la corde.
2  0 
Avatar de TotoParis
Membre éprouvé https://www.developpez.com
Le 17/01/2022 à 14:14
Citation Envoyé par BicBac Voir le message
Ce qui est terrible c'est qu'on associe open-source et gratuit.
C'est toujours le cas, ou alors il faut être très précis dans la licence du logiciel. Ou ne pas faire de l'open source, ce qui n'est pas incompatible avec du gratuit (comme le "freeware".
Et va gérer des licences payantes sur du JavaScript...
1  1 
Avatar de miaous
Membre averti https://www.developpez.com
Le 18/01/2022 à 13:36
Citation Envoyé par grunk Voir le message
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.
Je ne sais pas si ca existe sur les gestionnaire de dépendances, mais il faudrait pouvoir mettre une limite (surchargable) sur le nombre de dépendances en cascade pour avoir conscience que l'import de truc va appelle bidule qui lui meme appel machin1 , machin2.
0  0