« Nos clients payants ont besoin de X, quand allez-vous corriger ça ? »
(twitter.com/maximilianhils)- Un utilisateur en entreprise ayant des clients dans des secteurs réglementés (banques, agences fédérales, etc.) a exigé dans une issue publique le calendrier de la prochaine release de l’outil open source mitmproxy, en faisant pression au motif que ses propres clients ne pouvaient pas utiliser le logiciel à cause de vulnérabilités High et Critical connues
- Or, la vulnérabilité en question se trouvait dans une partie d’une bibliothèque que mitmproxy n’utilise pas, donc sans impact réel pour les utilisateurs
- Le mainteneur n’a pas refusé la demande ; il a répondu que, si une release de correctif dans les délais était nécessaire, ils pouvaient conclure un contrat de support payant (support contract), et il a indiqué l’adresse e-mail de son profil
- L’utilisateur en entreprise a protesté par e-mail, disant avoir perçu cette réponse comme une « plaisanterie ou une tentative d’extorsion habilement déguisée »
- La question sur le calendrier de release était en soi légitime, mais le point essentiel est qu’elle doit s’inscrire dans une attitude coopérative du type « comment pouvons-nous aider, par une contribution ou un financement ? » ; l’auteur du commentaire initial a ensuite présenté des excuses sincères
Contexte de l’incident
- D’après l’explication de contexte jointe, une bibliothèque distribuée avec mitmproxy comportait une vulnérabilité, mais dans une partie non utilisée par mitmproxy, donc sans impact réel pour les utilisateurs
- Des explications supplémentaires ont été fournies après que l’affaire est devenue virale (went viral) à l’extérieur
Demande initiale de l’utilisateur en entreprise (issue GitHub)
- Il y a 16 heures, un utilisateur a mentionné un autre membre du projet, @Prinzhorn, pour demander une date cible (target date) pour la prochaine release
- Il a expliqué que des clients dans des secteurs réglementés (regulated industries), comme les banques et les agences fédérales, n’ont pas le droit d’utiliser un logiciel comportant des vulnérabilités connues de gravité High ou Critical
- Il disait devoir définir la position de son entreprise sur l’attente, mais avoir besoin pour cela d’une forme quelconque de date cible
Réponse du mainteneur mhils
- Le membre mhils a répondu 15 heures plus tard qu’il serait disposé à mettre en place un contrat de support si l’entreprise souhaitait une release de correctif dans les délais afin de satisfaire ses exigences de conformité
- Il a indiqué que ses coordonnées figuraient dans l’e-mail de son profil (avec la mention ":-)")
E-mail de protestation (« Concerning response »)
- Par la suite, un e-mail intitulé « Concerning response » a été envoyé depuis un domaine us.ibm.com vers github@hi.ls (daté du 14 juillet 2023)
- Le message, qui commence par « Mr. Hils », explique que l’objectif était d’obtenir une réponse directe en précisant mieux la demande de date cible, plutôt que d’envenimer la situation ou d’encombrer inutilement l’issue GitHub
- Il précise espérer que ce message de suivi ne sera pas mal pris, car ce n’était pas son intention
- Dans le passage mis en évidence, l’auteur dit supposer que la réponse du mainteneur n’était pas une réponse officielle du projet mais une plaisanterie, ou pire, une tentative d’extorsion habilement déguisée (thinly veiled extortion attempt) (la phrase s’interrompt ensuite alors qu’il examinait la documentation officielle du projet)
Position du mainteneur
- Il précise clairement que sa réponse n’était pas une plaisanterie
- Une approche du type « nos clients payants ont besoin de X, quand allez-vous corriger ça ? » n’est peut-être pas la meilleure manière de se présenter à un projet open source
- Il reconnaît toutefois que la question sur le calendrier de release n’est pas dérangeante en soi et qu’il s’agit d’une question légitime (valid)
- Le point clé est plutôt que le contexte devrait être « nous nous intéressons à ce sujet, comment pouvons-nous aider à le concrétiser ? » (contribution ou financement), et non « vous créez un problème pour nos clients »
Conclusion
- L’auteur du commentaire initial a ensuite envoyé des excuses sincères (genuine apology), que le mainteneur dit avoir sincèrement appréciées
- Il demande à chacun de partir du principe de la bonne foi (assume good intentions) et de se montrer bienveillant
1 commentaires
Avis de Hacker News
En lisant cette issue https://github.com/mitmproxy/mitmproxy/issues/6051, la demande d’IBM est bien plus raisonnable que ce que le tweet laisse paraître.
Le problème est qu’il existe une CVE dans une dépendance de mitmproxy ; mitmproxy a mis à jour cette dépendance en mars, mais n’a pas encore publié de version stable contenant cette mise à jour. Côté IBM, la question est : « Quand prévoyez-vous de taguer une release, et avez-vous un calendrier que nous puissions communiquer à nos clients ? »
En particulier, ils ne demandent pas « quand allez-vous corriger ça ? ». Il n’y a déjà plus rien à corriger ; la question est plutôt « quand prévoyez-vous de faire une nouvelle release incluant cette mise à jour de dépendance ? »
Je ne trouve pas cette question injustifiée en soi. Bien sûr, si l’on veut que ce correctif soit livré dans un délai donné, il n’est pas injustifié non plus de demander un contrat de support, mais la réponse immédiate « contactez-nous par e-mail pour un contrat de support » me semble un peu excessive.
Maximilian n’a aucune obligation de fournir un calendrier de release à quelqu’un qui ne paie pas, et il n’y a rien d’étrange à suggérer à IBM de payer si elle a vraiment besoin d’un planning. Si IBM juge cela si important, elle pourrait même créer dès aujourd’hui sa propre release interne de mitmproxy.
Si j’ai répondu « contactez-nous par e-mail pour un contrat de support », c’est parce que 1) j’avais déjà indiqué dans ce fil que nous ne publierions pas de patch release pour ce cas, et 2) l’interlocuteur insistait sur l’impact pour ses propres clients payants.
À ce stade, c’était donc la seule chose à ajouter. Je suis d’accord pour dire que j’aurais pu mieux le formuler, mais je n’ai pas le sentiment que ma réponse ait été totalement excessive.
La CVE elle-même est aussi bidon, et nous n’utilisons pas cette partie de la dépendance concernée.
Pourquoi le mainteneur devrait-il travailler gratuitement pendant que le demandeur tire profit de ce travail gratuit ?
Ce qui est abusif, c’est l’attitude de FrugalGuy, qui considère cela comme acquis. Il faut être d’une hypocrisie assez particulière pour exiger d’un mainteneur open source qu’il travaille gratuitement, puis l’accuser d’extorsion. On ne peut pas imposer des exigences à un bénévole qui maintient un projet libre et open source à temps partiel.
Je suis l’OP. Pour être clair, la question sur la release elle-même ne pose absolument aucun problème et est légitime.
Mais le contexte devrait être : « cela nous intéresse, comment pouvons-nous aider à le faire aboutir ? », que ce soit par une contribution ou par de l’argent. Pas : « à cause de vous, nos clients ont un problème ».
Je ne souhaite pas que le demandeur soit accablé pour avoir mal choisi ses mots ; je souhaite que les grandes entreprises entretiennent une relation saine avec les logiciels libres et open source.
Le simple fait d’avoir proposé un tel contrat était en réalité plutôt généreux. FrugalGuy aurait aussi pu recevoir comme réponse « envoyez une pull request », et je ne sais pas si cela lui aurait plu.
Mais si le problème est l’absence de release pour un correctif déjà réalisé, je ne vois pas très bien comment une contribution ou de l’argent pourrait régler cela.
Ça ressemble à l’archétype des idiots de l’infosec qui ne savent même pas ce qu’ils sont en train de « corriger ». Le genre de personnes qui pensent que, si un système automatisé leur signale une CVE, il faut forcément la « patcher »
Ils ne regardent pas ce que la CVE affirme, ni si leur usage précis est vulnérable. Ils ne savent pas, ça ne les intéresse pas, et ce ne sont pas des programmeurs. Ils savent seulement qu’il faut cocher la case comme résolue
Il s’est passé quelque chose de similaire avec h2database. Un « chercheur en sécurité » a découvert que de mauvaises choses se produisent si l’on fait quelque chose qu’il est déconseillé de faire, et il a quand même demandé et obtenu une CVE. Quand on regarde de près, on voit que c’est du n’importe quoi, mais pour ce genre de personnes, seul compte le fait qu’une CVE existe
Ce qu’a dit un développeur de h2database : https://github.com/h2database/h2database/issues/3686#issueco...
« J’ai du mal à comprendre pourquoi on devrait avoir la moindre sympathie pour des “grandes entreprises” qui utilisent un projet open source développé par des bénévoles. Qu’elles embauchent quelqu’un avec l’argent de l’entreprise pour s’en occuper, ou qu’elles paient pour une bibliothèque commerciale équivalente »
Même s’ils ont le pouvoir d’accorder une exception dans un cas précis, ils peuvent devoir remplir davantage de paperasse pour justifier cette décision. Cette paperasse supplémentaire les ralentit et joue contre eux dans leurs indicateurs d’évaluation
« Si l’on passe un mot de passe en ligne de commande, d’autres processus du système peuvent le voir avec ps »
C’est une évidence. Si ça vaut une CVE de « gravité élevée », alors on peut aussi m’appeler chercheur en sécurité. Je peux citer au moins une demi-douzaine d’applications qui autorisent exactement la même chose tout en ajoutant un avertissement du type « ne faites pas ça »
L’équipe infosec remonte une vulnérabilité apparue dans un rapport, et le manager prend peur
Le développeur doit continuer à mettre à jour. Même les dépendances qui ne sont pas en production. On peut demander une exception, mais c’est un tout autre casse-tête
Puis le manager se demande pourquoi le développement a ralenti
Je me demande même si quelqu’un examine réellement le reste des réponses
Sur l’un de mes projets aussi, j’ai soudain vu affluer des commentaires du type « quand allez-vous corriger ça », « je suis aussi touché et c’est important ». Cet intérêt soudain était assez étrange
Mais à peu près au même moment, j’ai reçu un e-mail d’excuses du supérieur hiérarchique de quelqu’un dans une entreprise, expliquant qu’il avait demandé à ses employés de me mettre la pression en faisant croire que bien plus de personnes étaient affectées qu’en réalité
On dirait que quelqu’un a appris que, dans son entreprise, un ton agressif ou menaçant était très efficace, sans comprendre que le rapport de force dans la négociation est ici complètement différent
Il y a une nuance subtile entre « j’ai besoin de savoir quand ce sera prêt pour pouvoir planifier » et « je suis payé grâce à votre travail, donc vous devez faire ça, et vite »
Si la personne qui faisait la demande avait omis le contexte, le ton aurait été plus proche du premier cas et moins du second
Si cette raison semble importante pour beaucoup d’autres utilisateurs, cela peut aider le mainteneur à décider s’il doit prioriser une fonctionnalité ou une correction de bug. Et s’il existe un contournement, cela peut aussi aider à le trouver
Le fait de parler d’extorsion envers le développeur était injustifié, mais je pense que le premier message en lui-même n’avait rien de problématique
Le sentiment de droit acquis des entreprises qui utilisent de l’open source tout en exigeant du support est énorme. J’aimerais que les licences avec restrictions d’usage soient plus répandues, et que l’OSI ne se contente pas de dire « ce n’est pas de l’open source !!! »
Ce genre de licence pourrait éviter ce type de situation.
Quoi qu’il en soit, c’est une bonne chose que l’OSI et la FSF adoptent ici une position ferme. Si vos priorités ne correspondent pas aux leurs, pourquoi devraient-elles changer pour vous satisfaire ?
Utilisez simplement la licence qui vous plaît. Même si elles ne l’approuvent pas. Je ne vois pas en quoi c’est un problème. Si, dès le départ, vous ne partagez pas leurs valeurs, pourquoi ces organisations devraient-elles apposer leur tampon d’approbation sur votre choix de licence ?
Pour les sponsors corporate, le fait de ne pas soutenir les restrictions d’usage n’est pas un bug, c’est une feature.
Il y a aussi un dogmatisme énorme autour des définitions de l’open source et du logiciel libre. Si vous ne vous conformez pas à ces définitions, il est facile de se faire attaquer en meute, et elles sont souvent traitées comme des textes sacrés. Leurs partisans refusent même d’envisager qu’un ajustement puisse être nécessaire pour coller à la réalité de 2023.
Même quand on crée de nouveaux termes pour éviter le conflit, les défenseurs de l’open source et du logiciel libre insistent pour imposer leur propre vocabulaire et contrôler le récit. Ce vocabulaire est conçu pour porter des connotations négatives au sein de leur communauté.
La liberté pour l’utilisateur d’exécuter le logiciel à n’importe quelle fin est la liberté 0, et Stallman explique de façon très convaincante pourquoi les restrictions d’usage n’aident pas : https://www.gnu.org/philosophy/programs-must-not-limit-freed...
Comme les clauses de non-garantie, le logiciel libre est fourni sans condition. Recevoir en plus le cadeau de la liberté de le modifier comme on le souhaite, puis exiger du support et de la maintenance gratuits, c’est impoli. Je ne pense pas que changer de licence ferait disparaître ces gens impolis.
Et il pourrait y avoir des options plus favorables à l’open source qu’aux entreprises sans passer par une licence. Par exemple, exiger que quelqu’un qui signale un problème critique publie du code de reproduction.
Même dans les années 80, à une époque où le support était souvent fourni gratuitement, j’ai entendu beaucoup d’histoires d’entreprises qui faisaient ce genre de choses avec des logiciels piratés. La seule chose qui a réduit ces abus, ce sont les contrats de support payants.
La seule réponse réaliste serait d’intenter une action pour violation de licence, mais peu de développeurs open source ont les moyens de le faire face à une grande entreprise, voire même à une entreprise de taille moyenne.
Le comportement de « FrugalGuy » est immature et puéril, mais le mainteneur de mitmproxy aurait pu répondre d’une meilleure manière, polie mais ferme, sans laisser de place au malentendu ni au drama :
« Conformément à la licence de mitmproxy, ce logiciel est fourni en l’état, sans garantie, et les mainteneurs du projet sont actuellement pris par d’autres priorités et livrables. »
« Par conséquent, les seules déclarations dans le tracker d’issues GitHub ne suffisent pas à justifier une priorisation de ce problème. Le seul moyen d’augmenter sa priorité est de conclure un contrat de support, disponible [here]. Nous serons ravis de discuter plus avant des conditions. »
Le coût d’un an de salaire d’ingénieur, pour certaines tailles d’entreprise, ce n’est rien, et il semble possible que le correctif soit fait en quelques semaines ; ce serait équitable.
Ou alors, s’ils ne veulent vraiment pas payer, ils peuvent affecter un de leurs ingénieurs pendant quelques mois pour patcher ce dont leurs clients payants ont besoin et contribuer le changement upstream.
Correction : dire un an de rémunération d’ingénieur n’était qu’une estimation limitée et imprécise de ma part. Je ne suis pas en position de dire combien cela vaut exactement, mais j’estime qu’un ingénieur qui ne connaît pas la base de code y passerait probablement quelques mois d’effort.
Mais cela pourrait créer d’autres problèmes de conformité, et c’est sans doute pour cela qu’ils ne l’ont pas fait. Bien sûr, ce n’est pas le problème du projet open source.
https://github.com/mitmproxy/mitmproxy/issues/6051#issuecomm...
Demander simplement « avez-vous une date cible pour la prochaine release ? » n’est pas problématique, parce que ce n’est pas une exigence.
Dans « j’essaie de construire notre argumentaire interne pour attendre, mais j’ai besoin d’une date cible », le « besoin » se lit comme une exigence venant d’autres personnes envers lui, pas comme une exigence adressée aux développeurs de mitmproxy.
Dans ce commentaire, il formule une demande tout en expliquant ses motivations commerciales et personnelles. Il n’y avait pas de problème jusqu’à ce qu’il revienne par e-mail avec des mots comme extorsion.
Le post original contenait à la fois le contexte et l’employeur. Il est évident que l’auteur cherchait volontairement à éviter cela ; diffuser la vraie issue GitHub est aussi un comportement assez minable.
FrugalGuy, vraiment, je n’ai pas les mots.