Pourquoi une minorité de développeurs pourraient gâcher le potentiel de l’open-source ?

L’un des aspects les plus étonnants de l’open-source n’est pas qu’il produise d’excellents logiciels. C’est que tant de développeurs mettent leur ego de côté pour créer de grands programmes avec l’aide des autres. Reste qu’une poignée de programmeurs font désormais passer leurs propres préoccupations avant le bien du plus grand nombre et risquent de ruiner les logiciels à code source ouvert pour tous.

Prenez par exemple le cas du mainteneur du gestionnaire de paquets JavaScript RIAEvangelist, Brandon Nozaki Miller. Ce dernier a écrit et publié un paquet open-code npm appelé peacenotwar. Il ne fait rien d’autre qu’imprimer un message de paix sur les ordinateurs de bureau. Jusqu’ici, rien d’alarmant. Le développeur a toutefois inséré un code malveillant dans le paquet pour écraser les systèmes de fichiers des utilisateurs si leur ordinateur avait une adresse IP russe ou biélorusse. Il l’a ensuite ajouté comme dépendance à son populaire programme node-ipc dans le but de provoquer le chaos. Un plan couronné de succès : de nombreux serveurs et PC sont tombés en panne lors de la mise à jour du code, puis les disques durs de leurs systèmes ont été effacés.

Pour sa défense, le développeur a indiqué que “tout ceci est public, documenté, sous licence et open source”. Un argumentaire qui ne tient pas la route, pour Liran Tal, chercheur chez Snyk. Même si l’acte délibéré et dangereux [est] perçu par certains comme un acte légitime de protestation, comment cela se répercute-t-il sur la réputation future du mainteneur et sur son rôle dans la communauté des développeurs ?  Pourrait-on encore faire confiance à ce mainteneur pour ne pas donner suite à de futurs actes de ce type ou à des actions encore plus agressives pour tout projet auquel il participe ?”, s’interroge ce dernier.

L’enfer est pavé de bonnes intentions

Pourtant, Brandon Nozaki Miller n’est pas n’importe qui. Il a produit beaucoup de bon code, comme node-ipc, et Node HTTP Server. Mais, pouvez-vous faire confiance à son code pour qu’il ne soit pas malveillant ? Bien qu’il le décrive comme “pas un logiciel malveillant, [mais] un logiciel de protestation qui est entièrement documenté”, d’autres ne sont pas de cet avis.

Comme l’a écrit un programmeur de GitHub, “Ce qui va se passer, c’est que les équipes de sécurité des entreprises occidentales qui n’ont absolument rien à voir avec la Russie ou la politique vont commencer à considérer les logiciels libres et open-source comme une avenue pour les attaques de la chaîne d’approvisionnement (ce qui est tout à fait le cas) et commencer simplement à interdire les logiciels libres et open-source – tous les logiciels libres et open-source – au sein de leurs entreprises”.

Pour un autre développeur GitHub, “le facteur de confiance de l’open source, qui était basé sur la bonne volonté des développeurs a pratiquement disparu, et maintenant, de plus en plus de gens réalisent qu’un jour, leur bibliothèque/application peut éventuellement être exploitée pour faire/dire tout ce qu’un développeur aléatoire sur Internet a pensé “être la bonne chose à faire”. Autant d’arguments valables. En effet, lorsque vous ne pouvez pas utiliser le code source si vous n’êtes pas d’accord avec la position politique de son créateur, comment pouvez-vous l’utiliser en toute confiance ? Si l’activisme de Brandon Nozaki Miller est louable, ses méthodes risquent en revanche de miner la confiance dans les logiciels libres.

L’open-source ne fonctionne en effet que parce que nous lui faisons confiance. Lorsque cette confiance est rompue, quelle qu’en soit la cause, le cadre fondamental de l’open-source est brisé. Comme l’a dit Greg Kroah-Hartman, le mainteneur du noyau Linux pour la branche stable, lorsque des étudiants de l’Université du Minnesota ont délibérément essayé d’insérer du mauvais code dans le noyau Linux pour une expérience en 2021 : “Ce qu’ils font est un comportement malveillant intentionnel et n’est pas acceptable”.

Les limites de l’open-source

Nombreux sont les acteurs du secteurs à soutenir que les logiciels libres devraient également inclure des dispositions éthiques. Par exemple, la licence publique générale d’exception (eGPL) de 2009, une révision de la GPLv2, a tenté d’interdire aux “exceptions”, telles que les utilisateurs et fournisseurs militaires, d’utiliser son code. Elle a échoué. D’autres licences, comme la licence JSON, avec sa clause gentiment naïve “le logiciel doit être utilisé pour le bien et non pour le mal”, existent toujours, mais personne ne la fait respecter. 

Plus récemment, l’activiste et développeur de logiciels Coraline Ada Ehmke a introduit une licence de logiciel libre qui oblige ses utilisateurs à agir moralement.  Plus précisément, sa licence Hippocrate a ajouté à la licence open-source MIT une clause stipulant : “le logiciel ne peut pas être utilisé par des individus, des sociétés, des gouvernements ou d’autres groupes pour des systèmes ou des activités qui mettent activement et sciemment en danger, nuisent ou menacent de toute autre manière le bien-être physique, mental, économique ou général d’individus ou de groupes défavorisés, en violation de la Déclaration universelle des droits de l’homme des Nations unies.”

Si l’intention est louable, elle revient à ne plus faire de l’open-source. L’open-source est en soi une position éthique. Son éthique est contenue dans les quatre libertés essentielles de la Free Software Foundation (FSF). C’est le fondement de toutes les licences de logiciels libres et de leur philosophie de base. Comme le résume Eben Moglen, expert juridique en matière de logiciels libres et professeur de droit à Columbia, les licences éthiques ne peuvent pas être des licences de logiciels libres ou de sources ouvertes.

Mauvaises intentions

Malheureusement, les personnes qui essaient d’utiliser le logiciel libre pour ce qu’elles considèrent comme un objectif éthique supérieur ne sont pas les seules à causer des problèmes aux logiciels libres. Au début de cette année, le développeur JavaScript Marak Squires a délibérément saboté ses obscures, mais vitales, bibliothèques Javascript open-source “colors.js” et “faker.js”. Le résultat ? Des dizaines de milliers de programmes JavaScript ont explosé.

Dans un post GitHub depuis supprimé, le développeur a justifié son geste en expliquant “ne plus vouloir soutenir les Fortune 500 (et d’autres entreprises de plus petite taille) avec mon travail gratuit. Il n’y a pas grand-chose d’autre à dire. Prenez cela comme une opportunité de m’envoyer un contrat annuel à six chiffres ou de bifurquer le projet et de demander à quelqu’un d’autre de travailler dessus.” Comme vous pouvez l’imaginer, cette tentative de chantage pour obtenir un salaire ne lui a pas réussi.

D’autres personnes insèrent aussi délibérément des logiciels malveillants dans leur code source ouvert pour le plaisir et le profit. La société de sécurité DevOps JFrog a ainsi découvert 17 nouveaux paquets malveillants JavaScript dans le dépôt NPM qui attaquent délibérément et volent les jetons Discord d’un utilisateur. Ceux-ci peuvent ensuite être utilisés sur la plateforme de communication et de distribution numérique Discord.

En plus de créer de nouveaux programmes open-source malveillants, d’autres personnes mal intentionnées prennent d’anciens logiciels abandonnés et les réécrivent pour y inclure des portes dérobées de vol de crypto-monnaies. L’un de ces programmes était event-stream. Un code malveillant y a été inséré pour voler des portefeuilles de bitcoins et transférer leurs soldes vers un serveur de Kuala Lumpur. Il y a eu plusieurs épisodes similaires au fil des ans.

Alors que faire ? Pour commencer, nous devrions examiner très attentivement quand, si jamais, nous devrions bloquer l’utilisation du code source ouvert. Plus concrètement, nous devons commencer à adopter l’utilisation du Software Package Data Exchange (SPDX) et du Software Bill of Materials (SBOM) de la Fondation Linux. Ensemble, ces outils nous permettront de savoir exactement quel code nous utilisons dans nos programmes et d’où il provient. Nous serons alors beaucoup plus à même de prendre des décisions en connaissance de cause.

Source : ZDNet.com