pylapp

GitHub

Les pièges de certains composants open source

🇫🇷 – dimanche 9 janvier 2022

Mots clés : #opensource, #FLOSS, #GitHub, #licences, #social

D'ordinaire nous aimons utiliser des bibliothèques tierces dans nos projets, ces “librairies” que l'on retrouve par exemple sur des forges logicielles publiques comme GitHub et GitLab. Rares sont les logiciels qui ne possèdent pas une once de FLOSS (Free Libre and Open Source Software) à l'intérieur. Le plus souvent, on retrouve dans chaque projet des composants FLOSS, que ce soit pour se faciliter la vie, écrire des tests unitaires ou gérer une base de données par exemple. On a vite tendance à prendre l'outil le plus connu, le plus répandu, ou à faire des réflexions trop rapides pour choisir ce dont on a besoin, et pourtant il y a des pièges à éviter.

Tout le monde est juriste, Ă©videment !

Beaucoup (trop) d'entre nous ne considèrent pas suffisamment la licence qui est appliquée à la libraire choisie ; par paresse intellectuelle, par pure fainéantise, par certitude de bien comprendre les licences, par oubli, ou par excès de confiance. On fait tous la boulette, et on en tire des leçons ensuite, ce n'est pas si anormal quand encore aujourd'hui dans les établissements de formation à l'ingénierie logicielle ou “les écoles de codage” on en parle assez peu, ou pas assez, voire pas du tout. Merci les formations au rabais vendeuses de rêves laissant leurs apprenants se fracasser sur le mur de la réalité.

Toutefois, parmi les pièges dans lesquels chacun et chacune peuvent plonger, il y en a particulièrement qui sont beaux. Et grossiers. Et pourtant, beaucoup de personnes se font avoir, et ne finissent par réagir que lorsque le sujet est médiatisé. Avant de se jeter sur le dernier composant à la mode, regardons en détails les pièges, en commençant par les licences évidemment.

Des clauses déloyales dans les licences

Par exemple, il y a quelques années, on pouvait trouver les frameworks React de Facebook / Meta sous une curieuse licence “BSD + Patents”. Le truc, c'est que cette licence possède des clauses relatives aux brevets (une vague idée ici). Si j'exagère et grossis les choses, le fait de chercher des noises en justice à Facebook à l'époque pouvait faire tomber le droit que vous aviez d'utiliser ses cadriciels (j'adore ce mot). Pot de terre contre pot de fer dans du béton armé, embêter Big F peut revenir à vous interdire d'utiliser ses technos, donc à retirer beaucoup de produits. Une fois la chose médiatisée, finalement Facebook changea son fusil d'épaule et utilisa la licence MIT.

Bref, attention aux clauses déloyales des licences !

Des changements radicaux de licences

Récemment encore, c'est HashiCorp qui changea brutalement la licence de son produit phare nommé Terraform, et l'entreprise est dans son bon droit. Le passage de la licence MPL 2.0 à la Business Source License a été fait avec fracas, justifié maladroitement par l'entreprise et décrié par la communauté open source. MongoDB a eu droit aussi auparavant à son concert de casseroles avec le passage à la SSPL. Pour aller plus loin, MariaDB propose cette page de FAQ sur la BSL. Benoit Sibaud (un chouette collègue chez Orange !) a rédigé et diffusé un billet abordant les “virevoltantes valses de licences libres et non libres dans les bases de données”, très instructif ! En d'autres termes, attendez-vous à peut-être voir des revirement de situations dingues sur les licences appliquées !

Le truc, c'est que quand bien même une entreprise décide d'agir ainsi, elle reste tout de même légalement dans l'obligation de satisfaire les demandes qui concernent les licences anciennement appliquées. Autrement dit, si à un instant T un composant C était sous une licence libre L (admettons GPL 3.0), mais que plus tard cette licence passe à une bullshit licence BL, si vous avez eu le composant sous licence L vous êtes en droit de demander les sources (si L l'autorise évidement), même si elles ne sont pas accessibles publiquement. Bon courage donc.

On peut ainsi imaginer jouer la prudence, et se dire que si on utilise des composants FLOSS, dans le doute, au cas où, on pourrait garder une copie du code source. J'apprécie beaucoup cet article de Geoffrey Dorme qui vous donnera davantage de motivations à le faire. En plus cloner les dépôts Git d'une organisation GitHub c'est facile pour l'instant.

Imaginez maintenant, malgré les trahisons précédentes, que certaines technos soient si répandues qu'elles en deviennent presque indispensables pour des entreprises, au hasard les frameworks comme React. Rien n'empêche Facebook / Meta du jour au lendemain de changer la licence, de rendre l'exploitation de l'outil payante, et de monter un vrai business model dessus. Un magnifique coup à jouer maintenant que le place est faite dans l'écosystème logiciel. Impossible ? C'est vite oublier le ramdam lorsque Oracle avait mis en place son JDK payant.

Mais il y a d'autres pièges plus gros encore...

L'ajout de clauses additionnelles

Prenons par exemple une librairie Java bien connue, qui est utilisée en production : Realm Java (la situation a été corrigée depuis, mais a trainé un bon moment tout de même pour que ce soit notable).

À première vue, si on regarde le README vaguement, on voit ceci :

Extrait du README annonçant que le composant est sous licence Apache 2.0

On peut alors en déduire que le composant est sous licence open source Apache 2.0. Sauf que trop de gens s'arrêtent là. Car que si on jette un œil au fichier de licence, on trouve certes des références à la licence Apache 2.0, mais aussi un autre élément d'enfoiré : l'export compliance.

Extrait du README annonçant que le composant est sous licence Apache 2.0 et qu'il y a une clause additionnelle

Vous pouvez retrouver le diff du commit sur GitHub, je vous met ci-dessous le contenu scélérat de cette clause, qui rend la licence non conforme à la définition donnée par l'OSI, donc plus open source du tout.

Clause indiquant que des éléments peuvent être soumis à la loi américaine et que si l'entreprise, le pays ou une personne de la société est sur liste noire l'usage du composant est prohibé

Pour celles et ceux qui n'ont plus assez de caféine dans le sang pour comprendre, voici un résumé : si on se retrouve sur une liste noire du gouvernement américain, que ce soit dans un pays, ou individuellement, ou dans une entreprise détenue par une personne dans cette liste noire, on ne peut pas utiliser ce produit.

En soit, quel est le soucis ?

Et bien le soucis est que l'on peut avoir des applications critiques ou indispensables, ou son produit tout bêtement qui, si un jour le client, l'éditeur, le pays, les actionnaires etc. sont dans le collimateur des États Unis d'Amérique, peuvent être dégagées des boutiques d'applications, avec toutes les conséquences que ça implique.

On peut espérer que ça n'arrivera jamais, ceci dit l'ère Trump a montré qu'il ne fallait pas grands choses pour que des fous furieux mettent la pagaille à l'échelle mondiale en interdisant l'usage de produits. Et le contexte international actuel ne rassure pas non plus vis à vis de la Russie. Demandez leur avis aux iraniens, cubains, ukrainiens ou chinois.

Bref, dit autrement, quand vous utilisez une librairie FLOSS, regardez sur GitHub la section dédiée à la licence. Si le texte “View licence” apparaît au lieu du nom de la licence, il y a deux cas de figure :

  • le texte a Ă©tĂ© modifiĂ© (souvent les copyrights) ou dĂ©corĂ© faisant que GitHub s'y perd ;
  • il y a du texte en plus dans le fichier. Ceci pouvant ĂŞtre des dĂ©tails sur d'autres licences appliquĂ©es ou d'anciens contributeurs, ou des clauses additionnelles.

Affichage des détails du projet GitHub indiquant peu d'infos sur la licence

Et oui, tout ça en droit français est valable.

Mais oĂą ailleurs peut-on se faire avoir ?

La plaie de l'excès de social dans les forges logicielles

Et si on regardait le nombre de commits ?

Déjà, pour “évaluer” un composant FLOSS, on peut regarder par exemple la vie de son code source. Ainsi, si un projet a des commits faits régulièrement, on serait en droit de se dire qu'il est toujours vivant. Toutefois la contraposée est fausse car on peut très bien avoir des projets FLOSS qui semblent “vivoter”, avec peu de commits réguliers mais qui fonctionnent très bien, tout simplement car le projet en lui-même peut être maintenu ponctuellement, discrètement, mais efficacement.

D'ailleurs regarder la date et le nombre de commits est aussi une fausse bonne idée, car par exagération on pourrait croire qu'un projet qui a beaucoup de commits est un projet de qualité, et fiable, ce qui est absurde. Dans la mesure où des outils comme Git permettent le squashing, les merge commits et le rebasing, on remarque bien que se fier uniquement à un historique de commits n'est pas viable. De plus, doit-on vraiment prendre en compte les commits et pull requests ridicules qui arrivent lors du Hacktoberfest quand celles et ceux qui les proposent veulent juste profiter du moment pour avoir un joli badge sur le profil GitHub par pur opportunisme ?

Est-ce que pour l'exemple ci-dessous le projet est vivant ou mort ? On peut s'y fier ou pas ? Pour faire des confettis, c'est suffisant ?

Historique Git d'un projet affiché sur GitHub montrant que le projet n'a pas bougé au mieux depuis 10 mois, voire depuis des années

Et Si On RegArDaIt LeS LiKes eT LeS FoLlOwErS ?

Les réseaux sociaux ont amené du pire dans GitHub avec les “likes” et les compteurs de “followers”.

Cet autre piège à éviter consiste à se contenter de regarder ces nombres de stars et de forks d'un projet sur la forge logicielle que l'on veut. Avec l'avènement des réseaux sociaux, on veut “liker”, “booster”, “up-voter” ou “starrer” des projets que l'on aime bien, ou que l'on pourrait aimer, ou pour faire plaisir au gars derrière qu'on connait. Mais en soit, ni le fonctionnel ni la qualité du projet ne sont par essence et par définition concernés. Il en est de même pour les forks ; il est courant de voir des utilisateurs en crééer juste... au cas où, pour grossir son profil GitHub, ou pour faire une pull request un jour ou pas. Surtout ou pas. Quand au nombre de “followers” du développeur principal, en quoi le fait qu'il en ait 2 300 au moins soit rassurant ? Le personnage peut être tout à fait exécrable, pénible voire même adepte de la pizza avec des patates dessus, pourquoi afficher cette fausse notoriété qui n'apporte rien ?

Est-ce que l'exemple ci-dessous est un gros projet ? Un truc balèze ? Non, c'est juste un programme affichant un train à vapeur si on se trompe de commande (moi j'adore).

Compteurs sociaux du projet avec 386 forks et au moins 2 600 forks

Environnement et qualité, beau code ou infect projet

On regarde les issues et requests ?

Un autre élément à considérer avec prudence est le nombre de issues et de pull requests / merge requests. En effet, un projet qui en possède beaucoup peut être un projet très vivant, comme aussi un projet qui est très à l'abandon mais avec une base d'utilisateurs réclamant des choses ou voulant contribuer sans personne derrière pour valider. Ou alors peut être victime de trolls, comme ce fut le cas pour le dépôt contenant l'algorithme de recommandations de Twitter. Prudence donc si on ne regarde que ces éléments sans les contextualiser.

On regarde les contributeurs ?

Chose intéressante aussi à voir, les contributeurs, ces petites mains visibles fournissant un incroyable travail.

Si vous utilisez un composant FLOSS avec un faible nombre de contributeurs, il est possible que derrière ce projet il n'y ait presque personne en dehors de quelques passionnés dévoués (bénévolement le plus souvent) à leur projet (pour la gloire plus que pour l'argent). Il faut donc se demander si le fait que le projet repose sur un tout petit nombre de contributeurs est bloquant ou pas. Pour une librairie affichant de confettis c'est peut-être un élément peu pertinent. Mais pour votre couche de chiffrement, est-ce une bonne idée de compter sur un seul péquin derrière ?

D'ailleurs, question bête, est-ce que l'on suppose que la source de vérité est... fiable ? Car pour être affichés comme contributeurs sur un projet GitHub, il faut apparaître à certains endroits dans les commits. Quid des personnes voulant rester anonymes ? Des personnes en pair-programming ? Ou d'une organisation faisant que le mainteneur principal s'acharne maladroitement à garder un historique Git propre et donc fait du copier/coller des pull requests mais en gardant à jour le fichier AUTHORS par honnêteté intellectuelle ? Ou des robots qui exécutent des tâches automatisées sur le dépôt et qui figurent dans les contributeurs ?

Ci-dessous un exemple, avec le projet Amaroq. A-t-on vraiment 13 contributeurs ou 1 seul ? D'ailleurs peut-on vraiment se contenter de mesurer l'activité par le nombre de commits ? Non, évidemment.

GitHub affichant les contributeurs, au nombre de 13
Détails des commits par contributeur montrant que finalement seulement un seul se démarque énormément

En parlant de commits et des contributeurs, peut-on vraiment faire confiance aux contributions ? Il y a des projets FLOSS qui exigent des signatures cryptographiques des commits d'une part, et que le Developer Certificate of Origin soit appliqué d'autre part. Engager les responsabilités de chacun et s'assurer que les commits soient intègres ne semble pas une mauvaise idée, mais a-t-on toutes et tous l'habitude de le faire ? Non. Méconnaissance ou fainéantise ?

La doc ?

D'ailleurs, on peut aussi regarder les échanges qui ont lieu dans les issues, les Slack ou Mattermost. Pour ce composant FLOSS qui vous intéresse, peut-être ne seriez-vous jamais amenés à échanger avec les mainteneurs derrière. Mais si vous voulez contribuer, êtes-vous prêts à dialoguer avec une équipe ayant une organisation pyramidale ? Ou concentrée sur un développeur quasi-messianique à qui tout le monde demande son avis et attend son accord ? Est-ce que l'ambiance est délétère dans le projet ?

On regarde le code source alors ?

Par ailleurs, jetez un Ĺ“il aussi au code source en lui-mĂŞme.

Si vous avez un projet iOS écrit en Swift, avec uniquement des compétences en Swift dans votre équipe, seriez-vous prêt à soumettre des pull requests sur un composant écrit en bon vieux Objective-C à la papy ? Si une librairie JavaScript vous plait pour faire des jolies animations, ça vous tente vraiment de l'utiliser sachant qu'elle va tirer jQuery et que vous êtes fiers de vous en être débarrassés y'a 2 ans ? Si le CERT signale de vulnérabilités critiques, et que le composant que vous voulez est concerné, comment et à quelle vitesse sont corrigées ces failles ? Il y en a certaines qui ne le sont toujours pas ? Et ils feront comment si le Cyber Resilience Act passe ? Si on voit plusieurs issues sur des vulnérabilités non corrigées, remontées par Dependabot ou Snyk peut-on nécessairement en conclure que ce composant est dangereux alors qu'un autre sans de telles choses le serait moins même si finalement il pourrait n'avoir en place aucun outil de détection ?

Les gens c'est bien aussi non ?

Truc rigolo, vous connaissez le développeur / grand chef derrière le composant que vous voulez ? Car peut-être politiquement engagé ou susceptible, ou impulsif, ou infect, et qu'il va saboter son projet ou pas, quitte à se faire virer de GitHub. Impossible ? Voyez plutôt.

Du coup...

Du coup, il n'y a pas de bons ou de mauvais composants FLOSS. Certains sont d'apparence plus fiables que d'autres, il faut les juger par leur efficacité mais pas uniquement ceci dit. Il faut rester prudent sur les licences altérées, batârdes ou simplement sur leur nature intrinsèque. S'intéresser à l’environnement, à l'ambiance, aux commits et au code source est une bonne chose également.

Il faut aussi envisager le fait qu'un projet finisse par mourir, que sa core team abandonne, que le moteur s'épuise. N'attendez pas pour les soutenir. N'attendez pas pour contribuer. N'hésitez pas les soutenir s'ils défendent des causes justes. L'open source c'est comme une kombucha : c'est super de récupérer une souche mère pour faire vos boissons, mais c'est mieux de partager vos souches filles à d'autres personnes pour qu'elles fassent pareil. À rester dans votre coin tout finira par pourrir et vous n'en tirerez plus grands choses. Prenez, améliorez, partagez et profitez.

Si vous voulez quelques pistes pour aborder les projets FLOSS, je vous partage ce support documenté, factuel et juste.

Message GitHub indiquant que le projet a été archivé par son propriétaire et qu'il est en lecture seule

— Dernière mise à jour : vendredi 25 août 2023 Précédemment sur paper.wf —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 2.0 Opinions are my own, even if I have some interests.

GitHub et les alertes Dependabot

🇫🇷 – dimanche 24 juillet 2022

Mots clés : #GitHub, #Dependabot, #alertes, #vulnérabilités, #CVE

Un peu de contexte

Au cas où vous ne le sauriez pas, GitHub propose plusieurs outils qui concernent les fuites de données (leaks) et les vulnérabilités (flaws). Par exemple, assez récemment, GitHub a mis en place un service de détection de leaks avec notamment deux volets : un basé sur des patterns pour les dépôts publics, et un autre plus complet pour l'édition Enterprise Cloud.

Depuis plus longtemps, GitHub peut afficher les alertes Dependabot, à savoir s'il existe des flaws sur des dépendances du projet, et cette fonctionnalité est gratuite et efficace !

Dependabot

En effet, en haut de votre dépôt, parfois cette bannière peut s'afficher. Et dans ce cas, il n'y a pas d'excuse pour aller voir ce qu'il se passe. Juste un bouton sur lequel cliquer. À savoir qu'il faut être membre du projet et authentifié sur GitHub pour voir ces alertes. C'est assez logique, autant éviter d'exposer à n'importe qui que l'on a une passoire dans le projet.

Une bannière d'alerte Dependabot indiquant que des vulnérabilités ont été trouvées dans les dépendances

Ainsi, en allant voir les choses de plus près, on peut tomber sur ce genre d'énumération de potentiels ennuis. Dès le début du parcours, on distingue plusieurs éléments pertinents, dont le niveau de sévérité, un titre plus ou moins explicite, la dépendance concernée et le fichier traité. J'adore NPM et Node.js pour leur lot d'alertes de vulnérabilités, on retrouve souvent les mêmes plateformes et environnements qui exposent autant de dépendances trouées, et ce n'est pas forcément surprenant ou anormal.

Une liste d'alertes Dependabot affichant les niveaux de sévérité et les dépendances incriminées

Ainsi, en choisissant une alerte, on accède à plusieurs données intéressantes dont la sévérité, la référence CVE, les versions concernées, et le cas d'exploitation de cette vulnérabilité. C'est très instructif et ça me parait complet pour le néophyte que je suis ! Bref, en cas d'alerte, on a assez de billes en main pour corriger.

Détails d'une alerte Dependabot avec les références CVE, une description technique de comment exploiter la faille et les versions incriminées

Du coup, comment faire pour ne rien rater de ces alertes ? Comment configurer mon dépôt allez-vous me dire ?

Configurer son dépôt

Première chose à savoir : il faut être... administrateur de son dépôt. Je ne comprends pas la logique, la gestion des droits sur GitHub étant toujours aussi grossière. Pourquoi devoir être administrateur, et donc avoir tous les droits, juste pour gérer les alertes ou s'y abonner ?

Ensuite, allez faire un tour dans les réglages du dépôt pour ajouter nominativement les personnes qui seront notifiées en cas d'alertes. C'est idiot, mais de base, personne n'est ajouté. Donc une alerte sur un dépôt peu actif peut très bien apparaitre sur GitHub, mais personne ne sera courant. Bref, ajoutez dans la section “Access to alerts” les membres de votre projet.

Définition des accès avec un champ de saisie de texte pour ajouter des personnes

Ensuite, jetez un œil à la section “Code security and analysis”. Il y a plusieurs options à activer comme les alertes Dependabot (pas certain que ce soit activé par défaut) et aussi la possibilité d'ouvrir des pull requests à chaque alerte pour corriger la situation. Pas d'excuse, même pour les flemmards !

Configuration des outils par dépôt avec plusieurs boutons

Configurer son compte GitHub

Enfin, allez faire un tour sur les réglages de votre compte GitHub, en commençant par la section “Notification” où vous pouvez vous abonner à des notifications de diverses formes.

Configuration des alertes et notifications par compte GitHub avec plusieurs boutons

Dernière chose, rendez-vous dans la section “Code security and analysis”, et activez les options ci-dessous. Oui, cela ressemble beaucoup à un volet de configuration pour les dépôts, je n'ai pas encore testé les différences, surement un niveau de précision (dépôt uniquement ou tous les dépôts du comptes) différent.

Configuration des derniers éléments par compte GitHub avec plusieurs boutons

Bref

Plus d'excuse maintenant pour laisser vos comptes GitHub et dépôts seuls, abandonnés devant ces vagues de vulnérabilités pouvant compromettre le projet et bien plus encore. En 5 minutes (et je suis large), les choses sont configurées, et le minimum proposé par GitHub dans sa forme gratuite parait déjà acceptable.

De plus, posez-vous la question suivante : si des dégâts venaient à être provoqués à cause d'une faille non corrigée, sur quelle tête les ennuis vont tomber ? D'autant plus que plus ça tombe de haut, plus ça fait mal en bas 🤯. Pour avoir discuté avec des développeurs lors de conférences et meetups, dans certaines entreprises (au moins deux ESN dont je tairais les noms, juste dire que l'une respecte la règle des A et l'autre fait partie des CASSOS), il est prévu dans le contrat de travail que c'est la responsabilité pénale du salarié développeur qui est engagée.

Raison de plus pour signer vos commits (histoire de vous dédouaner en cas d'ennuis et d'envoyer la patate chaude dans la friteuse), tout en vérifiant que tout est bien configuré avec Dependabot, et que des secrets ne sont pas divulgués !

Bref, sortez couverts !

— Dernière mise à jour : mardi 26 juillet 2022 Précédemment sur paper.wf —

Did you enjoy reading this blog? Give me a beer 🍺 or use something else ❤️‍🔥 Licensed under CC-BY-SA 2.0 Opinions are my own, even if I have some interests.