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 !

Faker.js, la bibliothèque intentionnellement corrompue par le développeur, est maintenant un projet contrôlé par la communauté
Et son développement sera assuré par une équipe de 8 personnes

Le , par Bill Fassinou

56PARTAGES

4  0 
Marak Squires, l'auteur principal de Faker.js a corrompu et supprimé la bibliothèque début janvier, mais elle est maintenant de retour sur la toile en tant que projet communautaire. Un référentiel GitHub a été créé pour le nouveau paquet faker.js, et une équipe de huit superviseurs a été constituée pour gérer le projet open source à l'avenir. De plus, un compte Twitter public a également été créé pour communiquer avec la communauté de la bibliothèque JavaScript. Entre-temps, le profil de Squires qui avait apparemment été suspendu par GitHub est à nouveau accessible.

L'on entend souvent dire qu'il est difficile de lever des fonds pour le développement de projets open source au point qu'il est dit que "l'open source est un destin qui ne fait pas de l'argent". Le développeur de la bibliothèque open source faker.js est récemment sorti de ses gonds pour détruire faker.js qu'il avait développée en raison de la difficulté de monétisation. Dans l'un des messages du développeur sur GitHub datant de novembre 2020, il a déclaré 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 ». Il n'a sans doute pas eu une suite favorable à sa demande, ce qui l'a conduit début janvier à corrompre deux des bibliothèques qu'il a lui-même conçues, facker.js et "colors.js", causant de ce fait des dommages à des millions de projets qui en dépendent. Squires a introduit un commit dans colors.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 ». Les utilisateurs ont bien évidemment compris que les bibliothèques venaient d'être compromises, mais étaient loin de s'imaginer que la personne à l'origine de la compromission est Squires lui-même. Il a bloqué des milliers de projets. Pour vous donner une idée de l'ampleur des dégâts, la bibliothèque colors.js a eu plus de 20 millions de téléchargements hebdomadaires uniquement sur npm et il y aurait près de 19 000 projets qui en dépendent.

De son côté, faker.js a eu plus de 2,8 millions de téléchargements hebdomadaires sur npm et plus de 2 500 utilisateurs. En réponse au geste de Squires, faker.js a été transformé en projet communautaire. Les tentatives pour le faire ont commencé. Facker.js, qui n'a existé que sur GitHub jusqu'à sa suppression par Squires au début du mois, a à présent un site Web selon lequel le développement de la bibliothèque sera maintenant assuré par une nouvelle équipe de huit personnes. Sur le site Web, il est également fait référence à la suppression par Squires. Selon la nouvelle équipe, "Squires a joué un mauvais tour à la communauté".

« Le projet Faker était géré par Marak Squires, un passionné de Node et un professionnel qui s'est mis en colère et a agi de manière malveillante le 4 janvier 2022. Le package a été supprimé et le projet a été abandonné. Nous avons maintenant transformé Faker en un projet contrôlé par la communauté, actuellement géré par huit ingénieurs issus de divers horizons et entreprises », indique le tout nouveau site Web de faker.js. Squires n'a pas commenté ces déclarations sur Twitter. Il a annoncé avoir corrigé le bogue Zaglo dans la bibliothèque JavaScript colors.js, mais ne pas avoir pu le télécharger sur le gestionnaire de paquets npm.



Depuis la suppression de faker.js début janvier 2022, la communauté et d'autres programmeurs intéressés discutent activement du sujet. Certains utilisateurs montrent d'une part de la compréhension pour l'action de Squires, qui a supprimé faker.js, mais ils continuent d'exprimer leur mécontentement face à cette action. En effet, 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. En outre, le rôle de GitHub dans cette affaire est également remis en question.

Certains ne sont pas d'accord avec le Fait que GitHub ait bloqué le compte de Squires. 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 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 », a-t-elle ajouté. Plusieurs personnes ont estimé que la suspension du compte de Squires était déraisonnable puisqu'il s'agissait de son propre code. GitHub a décidé plus tard de restaurer le compte de Squires, qui semble désormais être accessible. Quoi qu'il en soit, le comportement de Squires a à nouveau soulevé la question de la "surdépendance" des projets vis-à-vis des bibliothèques tierces.

Source : Faker.js

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de la décision de cette équipe de relancer le projet faker.js ? En ont-ils le droit ?
GitHub avait-il le droit de suspendre temporairement le compte de Squires ? Ce dernier avait-il violé une politique de la plateforme ?
Que pensez-vous de la "surdépendance" des projets vis-à-vis des bibliothèques tierces ?

Voir aussi

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

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

Un dev open source aurait volontairement corrompu des bibliothèques largement utilisées, affectant des tonnes de projets. Il avait précédemment demandé à être rémunéré pour son travail

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 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 confirmé 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 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 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 
Avatar de kain_tn
Expert confirmé https://www.developpez.com
Le 19/01/2022 à 11:33
Citation Envoyé par miaous Voir le message
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.
Alors je pense que ça dépend des gestionnaires mais quand tu analyses la qualité de ton code, tu peux/devrais aussi analyser ton arbre de dépendances. Tu as des outils pour ça, y compris des outils de visualisation.
0  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 24/01/2022 à 12:05
Autant des projets open source qui marchent peuvent être une super vitrine quand on cherche du boulot , autant là il s'est auto catalogué comme saboteur professionnel. Je lui souhaite de pas avoir à chercher du travail dans les quelques années à venir.
4  4 
Avatar de tontonCD
Membre habitué https://www.developpez.com
Le 31/01/2022 à 11:03
"A la base, c'est son projet, il est donc sensé pouvoir en faire ce qu'il veut, je ne comprends pas pourquoi il est banni par github."

Beaucoup de projets GitHub sont vérolés, parfois intentionnellement, il suffit alors de les récupérer et de les compiler pour installer un virus chez soi.
0  0