La pression
(daniel.haxx.se)- La maintenance de curl est devenue un travail à plein temps mêlant utilité publique, défi d’ingénierie et objectifs de qualité, et cela dure depuis des semaines d’environ 50 heures
- curl est une bibliothèque et un outil de transfert avec une base installée d’environ 30 milliards d’instances, ce qui crée une forte pression pour éviter qu’une défaillance de sécurité ne se propage aux utilisateurs
- Le flux actuel de signalements de sécurité est 4 à 5 fois supérieur à celui de 2024, et deux fois plus élevé qu’en 2025, avec en moyenne plus d’un signalement par jour, ce qui impose un traitement immédiat
- Le traitement de la sécurité comprend la vérification des affirmations, l’évaluation de la gravité, la rédaction des correctifs, l’identification du moment d’introduction, la rédaction des avis et la communication avec les chercheurs et l’équipe sécurité
- D’ici la prochaine publication, 12 vulnérabilités confirmées sont déjà en attente, et cette pression sans précédent met en lumière les limites du financement et du soutien humain
Le sens des responsabilités envers curl et la maintenance de long terme
- Le travail open source n’est pas motivé par l’argent ni par une vie glamour, mais par son sens social, son utilité publique et le défi d’ingénierie consistant à faire fonctionner les choses pour tout le monde
- Le travail sur curl est devenu une activité à plein temps à partir de 2019, représentant généralement environ 50 heures par semaine, de jour comme tard dans la nuit, en semaine comme le week-end
- L’objectif de curl est de devenir la meilleure bibliothèque et le meilleur outil de transfert possible, et d’être un projet de tout premier plan en matière de qualité, de performance et de sécurité dans l’open source
- curl n’est pas le projet d’une seule personne, et le curl actuel n’existerait pas sans les membres de l’équipe, mais beaucoup l’associent encore fortement à Daniel Stenberg en tant qu’individu
- Les critiques adressées à curl sont ressenties comme des critiques de décisions et de choix qu’il a soutenus ou pris lui-même, et curl est devenu un projet personnel qui a changé sa vie de façon permanente
- Fin 2026, le projet curl fêtera son 30e anniversaire, et le nombre d’installations de curl dans le monde est estimé à environ 30 milliards
L’évolution de l’environnement des signalements de sécurité
- Ces dernières années, l’environnement des signalements de sécurité de curl est passé de la frustration face aux LLM stupides aux rapports d’AI slop, à la fin du bug bounty puis au chaos de haute qualité commencé vers mars 2026
- Chaque fois qu’un grave échec de sécurité se répète dans les produits Internet, l’infrastructure logicielle ou l’open source, la pression augmente à cause du fait que curl est partout et qu’un tel incident ne doit pas arriver à curl ni à ses utilisateurs
- Le projet curl a progressivement réduit les risques de fuite ou de naufrage des défauts en ajoutant davantage de revues, de tests et de directives
Un niveau de vérification élevé, mais des risques persistants
- Après l’épisode où Mythos n’a trouvé qu’un problème de faible gravité lors de son premier scan, l’idée s’est imposée que curl est l’un des codes les plus relus, fuzzés et vérifiés que l’on puisse imaginer
- Cette situation n’est due ni au hasard ni à la chance, mais au résultat de décennies de travail acharné, d’attention aux détails et d’une amélioration itérative sans fin
- Même avec beaucoup de revue et de vérification, cela ne signifie pas l’absence de bugs ou de problèmes de sécurité : curl, c’est des centaines de milliers de lignes de code C assurant un réseau hautement parallèle sur de multiples protocoles, systèmes d’exploitation et architectures CPU
- Chaque problème, une fois découvert, est corrigé, puis un correctif est publié
- Une base installée mondiale d’environ 30 milliards signifie que curl est probablement présent plusieurs fois dans les téléphones, tablettes, voitures, téléviseurs, imprimantes, consoles de jeu et appareils de cuisine
- Par le passé, des projets devenus célèbres après avoir provoqué de gros bugs qui ont embrasé le monde pendant un temps ont attiré l’attention, et certains ont obtenu des financements et des effectifs suffisants pour embaucher plusieurs ingénieurs à plein temps
Un volume de signalements sans précédent
- Le rythme actuel des signalements de sécurité est 4 à 5 fois plus élevé qu’en 2024, deux fois plus élevé qu’en 2025, et dépasse en moyenne un signalement par jour
- La qualité des signalements est bien meilleure qu’auparavant, et ils sont généralement très détaillés et longs
- Comme les signalements continuent d’arriver, il faut si possible les traiter dès leur arrivée ; sinon, si le traitement ne suit pas le rythme, la liste des problèmes de sécurité potentiels continue de s’allonger
- Une liste incontrôlée de problèmes de sécurité potentiels constitue un poids mental
- À l’heure actuelle, l’essentiel du temps est consacré au traitement de la liste des problèmes de sécurité signalés sur HackerOne
- Les principales tâches consistent à vérifier les affirmations, évaluer la gravité, rédiger les correctifs, déterminer quand le bug a été introduit, comprendre la vulnérabilité, rédiger des avis de sécurité détaillés et communiquer avec les chercheurs en sécurité ainsi qu’avec l’équipe sécurité de curl
Pression sur la santé et sur l’équipe
- Pour la première fois, son épouse s’est inquiétée du temps consacré au travail et du déséquilibre entre vie professionnelle et vie personnelle, et son entourage s’inquiète aussi de la manière dont il absorbe cet afflux massif ainsi que du risque d’épuisement
- L’inquiétude pour les membres de l’équipe a également grandi, et il pourrait bientôt falloir réduire le temps de travail afin de retrouver un peu de marge de respiration
- La situation actuelle constitue une pression que ni le projet curl ni les membres de l’équipe sécurité n’avaient connue auparavant
- Le traitement des problèmes de sécurité est une priorité si élevée qu’il passe devant tout le reste du projet, et il n’est pas ignoré en raison du sens des responsabilités, de la conscience professionnelle et de la fierté du travail bien fait
- Dans la mesure où curl est un logiciel déployé sur des appareils du monde entier, le sentiment d’obligation de corriger ses problèmes de sécurité est fort
- Alors qu’il reste environ la moitié du cycle de publication avant la sortie prévue, il y a déjà 12 vulnérabilités confirmées, soit 12 annonces de CVE en attente
- C’est un record pour le projet, et cela signifie que 2026 atteindra 30 CVE publiques avant même d’être à moitié écoulée
- Si la tendance se poursuit, le nombre total de CVE curl publiées en 2026 devrait être au moins deux fois supérieur
Le soutien nécessaire et les limites structurelles
- À court terme, il est déjà trop tard pour obtenir une aide immédiate, car le volume de travail à traiter est déjà trop important
- Si davantage d’entreprises qui utilisent et dépendent de curl ou de libcurl dans des logiciels et services commerciaux apportaient un soutien financier, il serait possible de rémunérer plus de développeurs pour répartir la charge de travail
- Faire prendre en charge le coût par les employeurs via des contrats de support constitue aussi une voie possible
- De tels clients existent déjà, ce qui permet à certains membres de travailler sur curl à plein temps
- Cela dit, il n’y a pas vraiment d’attente qu’un changement significatif survienne rapidement dans ce domaine, et il est probable qu’une fois encore le projet traverse seul la tempête, comme dans d’autres phases inédites et plus difficiles
- Le projet curl n’appartient à aucune entreprise et ne dépend d’aucune structure faîtière
- Cette structure peut parfois entraîner un manque de ressources, mais elle offre en même temps un maximum de liberté et de souplesse
- La ligne de conduite du projet est de rendre curl aussi bon que possible pour le monde entier et pour les utilisateurs de curl
Les aspects positifs et l’état actuel
- Corriger les bugs et les problèmes est en soi une bonne chose, et chaque problème signalé signifie bientôt un problème corrigé
- Plus les signalements augmentent, meilleur devient curl
- Ces dernières années, toutes les vulnérabilités découvertes dans curl ont été évaluées comme LOW ou MEDIUM, et les vulnérabilités très graves ont été rares
- Cela ne signifie pas qu’il n’y aura plus jamais de niveau HIGH, mais au moins cela reste rare
- La plus récente CVE curl de gravité élevée est CVE-2023-38545, publiée en octobre 2023
- L’équipe curl est actuellement sous pression, et ses réponses peuvent parfois être lentes
1 commentaires
Avis sur Lobste.rs
J’espère que Daniel et les autres traverseront bien cette situation difficile sans impact majeur sur leur santé ou leur famille
Cela dit, la manière dont cette affaire va évoluer semble assez intéressante. Ce n’est pas la première fois qu’une nouvelle méthode d’analyse automatisée trouve soudainement beaucoup de vulnérabilités dans plusieurs projets FOSS, et cela rappelle aujourd’hui l’arrivée du greybox fuzzing dans les années 2010. Il semble y avoir trois scénarios possibles : A) les développeurs intègrent les LLM dans le flux de recherche en sécurité, ce qui fait fortement baisser le nombre de nouvelles vulnérabilités qu’ils trouvent, tandis que des vulnérabilités hors de portée des LLM continuent d’être découvertes, comme avec les fuzzers. B) similaire à A, mais après le passage des LLM, la découverte de vulnérabilités s’arrête pratiquement — le scénario où « les LLM résolvent la recherche en sécurité ». C) les vulnérabilités continuent d’être découvertes à un rythme élevé dans de gros projets comme curl, et le nombre de bugs dans des projets de plusieurs centaines de milliers de lignes de code est en pratique infini — le scénario de la « revanche de Tony Hoare »
Un instantané donné d’une base de code ne peut contenir qu’un nombre fini de bugs de sécurité. Une fois l’espace de recherche épuisé, le flot se calmera, et il ne restera ensuite que quelques bugs issus de fusions de code, de nouveaux test harnesses ou d’améliorations des modèles
Concernant le scénario C pour le projet curl, je pense que les bugs trouvés étaient de faible gravité justement parce que le niveau des tests de sécurité et des techniques classiques de détection de bugs y était déjà élevé. Cela montre qu’un investissement continu dans la détection de bugs finit toujours par payer à long terme. Cela restera vrai quelle que soit la méthode de découverte, aujourd’hui ou demain
Pour reprendre Marcus Hutchins, on est plus proche de l’idée que « la détection de bugs n’a jamais été le goulot d’étranglement ; le goulot d’étranglement, c’était la décision des organisations de ne pas investir dans les chercheurs en sécurité ». Les LLM ont simplement rendu cet investissement moins coûteux, et les organisations auraient toujours pu investir davantage pour trouver plus de bugs. Au final, c’est une décision de politique interne
Les entreprises qui développent la technologie LLM détruisent non seulement le monde naturel, mais aussi le monde du logiciel. Avec l’explosion du prix du matériel, l’informatique personnelle elle-même est menacée, tout comme les développeurs open source de bonne volonté qui créent parce qu’ils en ont envie
Il semble y avoir des moyens illimités pour rabaisser et casser les projets open source gérés par des communautés existantes, mais absolument aucun argent pour gérer les retombées, ce qui est intéressant
Je pense que cela prouve que Zig avait raison. Il suffit d’ignorer les CVE trouvées par des LLM, et de laisser cela à ceux qui ont envie de s’en occuper
Je sais bien que ce n’est pas exactement le cœur du sujet, mais le problème avec les CVE trouvées par des LLM, c’est que n’importe qui utilisant les mêmes outils pourra probablement trouver exactement les mêmes. Si un problème grave est effectivement découvert, cela signifie que davantage de gens peuvent s’en servir pour fabriquer quelque chose de malveillant
Bien sûr, cela ne veut pas dire que la même logique s’applique telle quelle au flot de problèmes de faible gravité ou non liés à la sécurité chez curl. Mais il faut quand même juger quels problèmes sont réellement prioritaires, et on revient alors à la case départ
Zig est encore en développement actif et, à chaque fois que des fonctionnalités comme la compilation incrémentale ou les E/S asynchrones se précisent, il est très probable que de nouveaux bugs soient introduits, tout en supprimant en même temps d’anciens bugs dus à des implémentations incomplètes
À ce stade du développement, si quelqu’un lançait quelque chose comme Mythos sur Zig avec l’idée de « trouver tous les bugs et ne jamais se tromper », cela produirait une énorme quantité de rapports, mais l’ensemble risquerait d’être pratiquement inutile pour nous. Aujourd’hui, la principale valeur d’un rapport de bug est de signaler qu’un utilisateur est bloqué dans un cas d’usage précis, et si on décide d’en faire une priorité, on peut débloquer cet utilisateur
Cela ne durera pas éternellement pour autant. Beaucoup de fonctionnalités importantes du compilateur sont en train d’être stabilisées et, une fois cela fait, trouver et corriger tous les bugs deviendra la priorité absolue. À ce moment-là, le fait qu’un bug soit connu deviendra important indépendamment de la manière dont il a été découvert, mais ce problème sera traité le moment venu
En attendant, la politique est simplement interdiction des LLM
Je comprends l’interdiction des contributions issues de LLM, mais je ne suis pas d’accord avec elle. Une vulnérabilité de sécurité reste une vulnérabilité, quelle que soit la manière dont elle a été trouvée
Je pense que l’approche de Daniel est la meilleure. Corriger les bugs que l’on peut corriger pour rendre les utilisateurs plus sûrs, tout en expliquant que le coût est élevé et en demandant du soutien. Il y a peu de chances qu’il lise ceci, mais je voudrais aussi soutenir et recommander qu’il limite sa charge de travail afin de faire passer sa santé physique et mentale en priorité. La plupart des gens le comprendront, et seule une minorité s’en plaindra probablement
Il semble qu’il manque ici deux points essentiels. 1) Ni les entreprises de LLM ni Project Zero n’ont introduit ces bugs de sécurité dans le code. 2) Corriger des bugs de sécurité ne sert pas les entreprises de LLM ni Project Zero, mais les utilisateurs. Ce sont les utilisateurs qui subissent les dégâts lorsque des bugs de sécurité sont exploités
Dans le cas particulier des bugs trouvés par des LLM, il y a déjà des signes que d’autres personnes utilisant le même LLM soumettent des rapports en doublon sur plusieurs projets open source. Il faut donc partir du principe que si les défenseurs laissent tomber, les attaquants finiront eux aussi par connaître les bugs découverts par LLM
« J’envie les projets qui, par le passé, ont publié des bugs horribles ayant mis le monde à feu pendant un moment. Ils ont attiré l’attention, et certains ont obtenu des financements et une puissance financière suffisante pour salarier du personnel et embaucher plusieurs ingénieurs à plein temps. Parfois, je me dis qu’il aurait peut-être mieux valu qu’on en ait un aussi »
Ce genre de chose arrive aussi dans beaucoup d’entreprises. On ajoute des effectifs aux équipes qui échouent, tandis que les équipes qui réussissent doivent faire plus avec moins de personnes précisément parce que rien de terrible ne leur arrive
Je ne sais pas si cela conviendrait à un projet comme curl, mais est-ce qu’un gel des fonctionnalités pendant un certain temps, afin de se concentrer uniquement sur les bugs/rapports de CVE entrants, pourrait aider ?
Avec un ensemble de fonctionnalités figé, le nombre de bugs/CVE potentiels est fini, et on peut imaginer qu’en les corrigeant on se rapproche de zéro
Quoi qu’il en soit, je leur souhaite bonne chance. Ce ne sera pas une période facile pour maintenir un logiciel aussi important
En termes de satisfaction des développeurs, cela produit respectivement une hausse, un maintien, puis une baisse
Le gel des fonctionnalités est un excellent outil pour bien finaliser une release, mais ce n’est pas un bon outil pour alléger la pression sur des développeurs qui travaillent de façon autonome selon leur propre cap