Si vous me faites perdre mon temps avec des signalements inutiles, je vous bannirai et me moquerai publiquement de vous

• Contenu indiqué dans /.well-known/security.txt du projet open source curl
• Le projet accepte les signalements de problèmes de sécurité découverts dans ses propres produits, mais n’offre aucune récompense financière ni aucun avantage en contrepartie pour les problèmes signalés
• À la place, pour les problèmes confirmés, il accorde des remerciements et une reconnaissance du mérite dans la documentation
• Il avertit que si quelqu’un fait perdre du temps avec des signalements médiocres ou dénués de sens, il s’expose à des moqueries publiques et à un bannissement
• Utilisation du format standard security.txt, qui résume de façon concise les points clés de la politique de signalement de sécurité

---

Politique de signalement de sécurité du projet curl

• Le projet open source curl reçoit les signalements de problèmes de sécurité concernant les produits développés par le projet curl
  • Les signalements peuvent être envoyés par e-mail ([e-mail]) ou via la page GitHub Security Advisories
• Il précise clairement qu’il n’existe aucune politique de récompense et qu’aucune compensation financière ou autre n’est fournie
  • En revanche, pour les problèmes confirmés, le projet offre des remerciements et une attribution du mérite dans la documentation associée

Avertissement concernant les signalements inappropriés

• Le projet indique explicitement : « Si vous me faites perdre mon temps avec des signalements inutiles, je vous bannirai et me moquerai publiquement de vous »
  • Il s’agit d’une formulation d’avertissement forte visant à empêcher les signalements non professionnels ou sans fondement
  • Cela met l’accent sur la qualité des signalements et sur une culture de divulgation responsable

Procédure de signalement et informations officielles

• Moyens de contact : e-mail ([e-mail]) et page GitHub Security Advisories
• Document de politique : publié sur https://curl.se/dev/vuln-disclosure.html
• Page de remerciements : disponible sur https://curl.se/docs/security.html
• Langue préférée : anglais (en)
• Date d’expiration de la politique : indiquée au 22 octobre 2026
• URL officielle : https://curl.se/.well-known/security.txt

[slowandsnow]

À cause de l’avalanche d’issues déposées sans discernement, fermer la page des issues GitHub semble être la seule solution.

[skageektp]

Je me demande si la moquerie publique n'est pas illégale en droit coréen aussi, haha

[GN⁺]

Réactions sur Hacker News

• J’ai vu récemment que cURL avait supprimé son programme de bug bounty face au déluge de faux rapports de bugs générés par l’IA
  Article connexe : fil Hacker News, article d’ETN

  • Si un rapport, un patch et même un cas de test sont correctement fournis, alors cela mérite selon moi une récompense, même si c’est généré par l’IA

• J’ai vraiment l’impression que l’ère de l’IA a commencé pour de bon

  • Tout le monde s’y attendait, et je suis même surpris que cela n’ait explosé que maintenant

• Je pense que le modèle de distribution open source est devenu structurellement non viable
  À l’origine, le mouvement du logiciel libre visait à garantir aux utilisateurs la liberté de corriger et d’améliorer eux-mêmes les logiciels
  Mais aujourd’hui, une culture s’est installée où l’on attend gratuitement un issue tracker, la revue des PR, le support par e-mail et les correctifs de sécurité
  En réalité, tout cela relève d’un travail de support payant, et sauf à le faire comme hobby, cela demande une compensation

  • J’avais autrefois créé un petit générateur de site statique avec HapiJS et je l’avais mis sur GitHub ; quand ça s’est propagé sur Reddit, j’ai été submergé de PR, de rapports de bugs et d’insultes
    Même après avoir dit que je n’avais « pas l’intention de fournir du support », j’ai continué à me faire attaquer, et ce fut mon premier et dernier projet OSS
  • J’imagine un système où les utilisateurs pourraient mettre une petite prime sur les fonctionnalités qu’ils veulent
    Si plusieurs utilisateurs veulent la même chose, la cagnotte grossit, et un développeur peut choisir de faire le travail
    Le chef de projet et les testeurs prendraient aussi une part, de sorte que tout le monde aurait une motivation
  • Je ne suis pas d’accord avec l’idée que les fondateurs de l’open source n’avaient pas ce type de modèle en tête
    Le modèle du Bazaar d’Eric S. Raymond et la « loi de Linus » (« avec suffisamment d’yeux, tous les bugs sont superficiels ») reposent précisément sur la collaboration ouverte
  • Je suis opposé à la vision qui présente les développeurs FOSS comme des victimes
    Il suffit de fixer soi-même des limites et des règles, puis de bloquer les gens impolis
  • La collaboration via des issue trackers publics comme GitHub est déjà devenue, sur deux générations, une culture de base de l’open source

• J’aide en ce moment le projet de documentation OWASP, et des étudiants indiens y ouvrent en masse des PR et des issues absurdes générés par des LLM
  Je propose un fonctionnement comme chez Ghostty : commencer d’abord par une « Discussion », puis ne convertir en PR que les issues approuvées par les mainteneurs

  • J’ai déjà vu chez des développeurs indiens une culture du « fake it till you make it », où l’on évite les questions et où l’on fonce simplement
  • Beaucoup d’étudiants envoient des PR avec du code LLM pour enrichir leur activité GitHub de CV, mais quand on leur demande des modifications, ils ne comprennent absolument rien
    Comme l’a dit Torvalds, grâce aux LLM, la maintenance du code risque de devenir un cauchemar
  • Quand ces PR sans intérêt se multiplient, il devient plus difficile de repérer les vrais problèmes
  • Je pense que l’une des raisons du déclin de Stack Overflow est aussi l’explosion des questions de mauvaise qualité

• Une fois, j’ai signalé un bug et j’ai été violemment pris à partie sur Reddit sous prétexte qu’il manquait des informations de reproduction
  Depuis cet épisode, j’ai presque totalement cessé d’utiliser les réseaux sociaux

  • L’équipe de curl demande généralement poliment des informations supplémentaires, donc si on n’y répond pas correctement, il est normal que le ticket soit fermé
  • Les mainteneurs peinent à trouver les vrais bugs au milieu d’innombrables faux signalements
    Il faut se rappeler que la critique vise le rapport, pas la personne
  • L’équipe de curl est au contraire plutôt indulgente, et les attaques sur Reddit n’ont rien à voir avec la communauté officielle
  • Ironiquement, même les réactions dans ce fil parlent d’une expérience qui est elle-même « impossible à reproduire »

• Pour résoudre le problème de l’Eternal September et des contributions de mauvaise qualité produites par les LLM, je pense qu’il faut au contraire plus de friction à l’entrée
  Par exemple, obliger un premier contributeur à envoyer son rapport sur une carte postale avec un QR code

  • Mais ce type de friction pourrait en réalité être inefficace, car les contributeurs spam ont tendance à mieux l’endurer que les vrais contributeurs

• Quand un projet se noie dans des PR pleines d’emojis et d’erreurs, le modèle du Bazaar a du mal à continuer à fonctionner

  • Cela me fait penser à la loi de Brandolini
    Le débordement d’informations non vérifiées n’est pas seulement un problème de l’open source, mais de la société dans son ensemble
    Notre culture ne dispose pas encore d’un système immunitaire contre la désinformation

• Cela me rappelle l’époque où The Pirate Bay publiait les e-mails de menaces juridiques envoyés par la MPAA
  On peut en voir une trace sur la page de réponses juridiques de TPB (archive web)
  Leur méthode n’était pas vraiment efficace, mais elle est restée comme une sorte de symbole de résistance

• Sur un projet open source connu qu’un ami maintient, des étudiants chinois soumettent comme devoirs de faux rapports de vulnérabilités de sécurité
  La plupart sont impossibles à reproduire et font perdre du temps aux mainteneurs
  En outre, à cause des différences de configuration selon les distributions, une vraie vulnérabilité peut parfois provenir non pas du code amont, mais de la configuration du paquet
  Sur le subreddit Kryptos K4 aussi, les messages de type « j’ai résolu ! » générés par des LLM débordent, donc au premier écart c’est bannissement immédiat
  Ce qui m’inquiète, c’est que la triche aux devoirs via l’IA se propage désormais à tous les domaines

  • En tant qu’êtres humains, nous ne devons pas perdre le plaisir d’apprendre et de progresser
    Peu importe les progrès de l’IA, la valeur de l’apprentissage par soi-même reste irremplaçable
  • Pour Kryptos K4, bien que les LLM connaissent toutes les données, ils n’apportent absolument aucune idée nouvelle
    Au final, les LLM ne sont pas un outil de pensée créative, mais simplement une autocomplétion améliorée
  • En Chine, il est fréquent que des étudiants en médecine ne rédigent pas eux-mêmes leurs articles et polluent les revues scientifiques avec des textes rédigés par des tiers
  • Au final, la fraude universitaire se propage vers le marché, et tant qu’il y aura des incitations financières, cela ne s’arrêtera pas

• Je pense que GitHub devrait attribuer aux utilisateurs un score de confiance ou un système de réputation

  • Mais GitHub dépend de la division IA (Microsoft CoreAI), donc il est fort possible qu’elle encourage au contraire ce type de comportement
    Article connexe : article de GeekWire
  • L’idée que Microsoft attribue un score social aux développeurs est terrifiante
  • À l’inverse, je pense qu’il vaudrait mieux anonymiser les utilisateurs afin de réduire la quête de réputation
  • Des plateformes comme HackerOne disposent aussi d’un système de réputation, mais les rapports de mauvaise qualité y pullulent toujours
    Au final, les entreprises finissent par payer des services de triage intermédiaire
    Dans ce processus, il arrive aussi que la première réponse vienne de personnes qui ne sont pas de vrais experts, ce qui retarde le traitement des vrais signalements
    La situation actuelle est mauvaise pour tout le monde et ne cesse d’empirer