CURL Says Go Outside And Touch Some Grass
Le projet curl instaure un « Summer of Bliss » en juillet 2026, suspendant totalement la réception et le traitement des rapports de vulnérabilité pour permettre à l’équipe de prendre des vacances et de lutter contre l’épuisement professionnel, tout en maintenant le support pou...

SYNTHÈSE STRUCTURÉE
Une pause totale des rapports de sécurité
Pendant tout le mois de juillet 2026, curl n’acceptera ni ne traitera aucun rapport de vulnérabilité. Le formulaire de soumission sur HackerOne sera mis en pause à partir du 1er juillet, et l’adresse email dédiée à la sécurité deviendra également inactive. Les soumissions reprendront le 3 août 2026 à 9h CEST. L’intervenant précise : « We do not accept vulnerability reports over email in general, and this fact remains during and after our vacation. So no circumventing the fact the HackerOne is closed. »
Un contexte de pression croissante
Cette décision fait suite à une période de « huge pressure for the last four months or so ». L’équipe curl est submergée par un afflux massif de rapports, en partie à cause de l’utilisation croissante de l’IA pour générer des signalements. L’intervenant explique que « maybe you would have gotten like one a day, or maybe one every couple of days. Now it’s multiple times a day, and every single one of these reports is massive ». Le bug bounty a également été « very abused many, many times », avec des personnes convaincues que leur rapport généré par IA allait leur rapporter de l’argent.
La maturité du projet comme justification
curl est un projet extrêmement mature : « the last report resolved was two months ago ». L’intervenant souligne que « this is not something which is constantly breaking over and over and over again ». Cette stabilité relative rend la pause moins risquée qu’elle ne le serait pour un projet plus jeune ou plus instable.
Un répit pour les mainteneurs
L’objectif principal est de permettre aux mainteneurs de se reposer et de se consacrer à des tâches plus gratifiantes. L’intervenant cite le message officiel : « The co-maintainers will use this time of less pressure to take in some extra air and enjoy the summer ». Il ajoute que certains pourront « spend some of this time to see other places » ou « get some extra time to spend on fixing bugs or working on new code. The fun stuff. »
Le problème de la disponibilité permanente dans l’open source
L’intervenant développe longuement sur la pression constante à être joignable, un phénomène amplifié par les technologies modernes : « You are now in this world where it is really easy for you to always be in work mode. Never escape work mode. » Il oppose cette situation à une époque où « if you weren’t near your phone, you didn’t exist ». Pour les développeurs open source, le problème est aggravé car ils travaillent souvent sur le même appareil qu’ils utilisent pour se détendre : « You’re just always surrounded by the work. »
L’impact sur le planning de publication
En conséquence directe de ce « Summer of Bliss », la sortie de curl 8.22.0 est repoussée de deux semaines, au 2 septembre 2026. Cela illustre que la priorité est donnée au bien-être de l’équipe plutôt qu’au respect strict d’un calendrier de release.
Une exception pour les clients payants
Les détenteurs d’un contrat de support payant continueront à bénéficier d’un service complet et approprié pendant cette période. L’intervenant explique que « money is a really good driver when you are otherwise doing a lot of things without getting paid ». Cela permet de filtrer les signalements légitimes des entreprises qui paient, par opposition aux rapports non sollicités et souvent non pertinents.
Des alternatives pour la divulgation responsable
Pour ceux qui ne souhaitent pas payer, il existe d’autres canaux : « You can send it up to the Linux distros and various other things like that. » L’intervenant rappelle que le processus normal de divulgation responsable implique déjà des délais de 30 à 60 jours avant publication publique, donc « cutting 30 days off the start, typically not normal, but at least holding on the report for a little bit usually is. »
Une réaction globalement positive de la communauté
Contre toute attente, la publication sur Hacker News a reçu un accueil plutôt favorable. L’intervenant note : « a lot of people are at least aware of the problem and personally suffer from the problem themselves. It’s just they’re not in a position to do anything personally about it. » Cela montre que le problème de l’épuisement dans l’open source est largement reconnu, même si peu peuvent agir.
Un appel à suivre l’exemple
L’intervenant encourage les autres projets open source à faire de même : « If you and your open source projects also want to participate in the Summer of Bliss 2026, just do it and let us know. » Il insiste sur l’importance de prendre soin de soi : « take care of yourself as a top priority. The bad guys won’t rest, probably not, but we will. »
CONCEPTS CLÉS
- HackerOne : Plateforme de bug bounty et de signalement privé de vulnérabilités utilisée par curl. Elle sera mise en pause pendant le Summer of Bliss.
- Bug bounty : Programme rémunérant les chercheurs en sécurité pour la découverte de vulnérabilités. Celui de curl a été victime d’abus, notamment via des rapports générés par IA.
- Divulgation responsable : Processus par lequel un chercheur signale une vulnérabilité à un projet, lui accordant un délai (généralement 30 à 90 jours) avant la publication publique, afin de permettre la correction.
- Summer of Bliss : Nom donné par l’équipe curl à cette période de pause estivale, en référence ironique au « Summer of Code » ou autres initiatives de développement intensif.
CONCLUSION
Le « Summer of Bliss » de curl est une décision audacieuse mais profondément humaine, qui met en lumière un problème systémique dans l’open source : l’épuisement des mainteneurs face à une pression constante et croissante. En sacrifiant un mois de réactivité sur les vulnérabilités, l’équipe curl choisit de préserver sa santé mentale et sa capacité à long terme, plutôt que de céder à une disponibilité toxique. Cette initiative rappelle que même les projets les plus critiques ont besoin de repos, et que le véritable risque n’est pas une vulnérabilité non traitée pendant 30 jours, mais une équipe épuisée qui finit par abandonner.