Se você me fizer perder tempo com relatórios inúteis, será banido e ridicularizado publicamente

• Conteúdo descrito em /.well-known/security.txt do projeto open source curl
• Recebe relatos de problemas de segurança encontrados em seus próprios produtos, mas não oferece recompensa em dinheiro nem benefícios de qualquer tipo pelos problemas reportados
• Em vez disso, para problemas confirmados, informa que dará agradecimento e crédito na documentação
• Adverte que, se fizerem o projeto perder tempo com relatórios ruins ou sem sentido, haverá ridicularização pública e bloqueio
• Usa o formato padrão security.txt para resumir de forma concisa os pontos centrais da política de reporte de segurança

---

Política de reporte de segurança do projeto curl

• O projeto open source curl recebe relatos de problemas de segurança em produtos feitos pelo projeto curl
  • Os relatos podem ser enviados por e-mail ([e-mail]) ou pela página de avisos de segurança do GitHub
• Deixa claro que não há política de recompensa, e não oferece compensação financeira nem qualquer outro tipo de benefício
  • Em vez disso, para problemas confirmados, concede agradecimento e reconhecimento de crédito na documentação relacionada

Aviso sobre relatos inadequados

• O projeto declara explicitamente: “se você me fizer perder tempo com relatórios inúteis, será banido e ridicularizado publicamente”
  • Trata-se de um aviso forte para evitar relatos não profissionais ou sem fundamento
  • Enfatiza a qualidade dos relatos e uma cultura de divulgação responsável

Procedimento de reporte de segurança e informações oficiais

• Meios de contato: e-mail ([e-mail]) e página de avisos de segurança do GitHub
• Documento da política: publicado em https://curl.se/dev/vuln-disclosure.html
• Página de agradecimentos: disponível em https://curl.se/docs/security.html
• Idioma preferido: inglês (en)
• Data de expiração da política: indicada como 22 de outubro de 2026
• URL oficial: https://curl.se/.well-known/security.txt

[slowandsnow]

Acho que a resposta é fechar a página de issues do GitHub por causa da abertura indiscriminada de issues

[skageektp]

Acho que o ridículo público também não seria ilegal pela lei coreana, né? kkk

[GN⁺]

Opiniões do Hacker News

• Vi recentemente que o cURL encerrou seu programa de bug bounty depois de ser inundado por relatórios falsos de bugs gerados por IA
  Artigos relacionados: thread no Hacker News, matéria da ETN

  • Se o relatório vier com patch e caso de teste bem feitos, acho que vale recompensar mesmo que tenha sido gerado por IA

• Estou sentindo que a era da IA realmente começou

  • Era algo que todo mundo já esperava, e o mais surpreendente é isso ter demorado tanto para explodir

• Acho que o modelo de distribuição de software open source se tornou uma estrutura insustentável
  O movimento original do software livre buscava garantir aos usuários a liberdade de corrigir e melhorar o software por conta própria
  Mas agora surgiu uma cultura em que se espera de graça tracker de issues, revisão de PR, suporte por e-mail e até patches de segurança
  Isso é, na prática, trabalho de suporte pago, e precisa de compensação a menos que seja só um hobby

  • Há um tempo fiz um gerador simples de sites estáticos com HapiJS e publiquei no GitHub; depois que se espalhou no Reddit, fui inundado por PRs, relatórios de bug e xingamentos
    Mesmo deixando claro que “não pretendia dar suporte”, as críticas continuaram, e aquele foi meu primeiro e último projeto OSS
  • Imagino um sistema em que usuários possam colocar pequenas recompensas nas funcionalidades que querem
    Se vários usuários quiserem a mesma feature, o valor acumulado cresce, e o desenvolvedor escolhe fazer aquele trabalho
    Gerentes de projeto e testadores também ficariam com uma parte, criando uma estrutura em que todos têm incentivo
  • Não concordo com a ideia de que os fundadores do open source não pretendiam um modelo assim
    O “modelo Bazaar” de Eric S. Raymond e a “Lei de Linus” (com olhos suficientes, todos os bugs ficam rasos) partem justamente da colaboração aberta
  • Discordo da visão de que desenvolvedores FOSS são vítimas
    Basta definir suas próprias fronteiras e regras e bloquear quem for grosseiro
  • A colaboração via issue trackers públicos como o GitHub já se consolidou como cultura básica do open source ao longo de duas gerações

• Tenho ajudado recentemente em um projeto de documentação da OWASP, e estudantes indianos estão abrindo em massa PRs e issues sem sentido gerados por LLM
  Sugeri uma estrutura como a do Ghostty, em que tudo começa em “Discussion” e só issues aprovadas pelos mantenedores podem virar PRs

  • Já vi entre desenvolvedores indianos uma cultura de “fake it till you make it”, evitando fazer perguntas e simplesmente tocando em frente
  • Muitos estudantes enviam PRs com código gerado por LLM para inflar a atividade no GitHub para o currículo, mas quando recebem pedidos de alteração, não entendem absolutamente nada
    Como o Torvalds disse, graças aos LLMs a manutenção de código parece prestes a virar um pesadelo
  • Quando esses PRs sem sentido se multiplicam, fica difícil encontrar os problemas reais
  • Acho que uma das razões da queda do Stack Overflow também foi a explosão de perguntas de baixa qualidade

• Certa vez enviei um relatório de bug e fui duramente atacado no Reddit por falta de informações de reprodução
  Depois disso, praticamente abandonei redes sociais

  • A equipe do curl normalmente pede informações adicionais com educação, então se você não respondeu direito, é natural que fechem o relatório
  • Mantenedores sofrem para encontrar bugs reais no meio de inúmeros relatórios errados
    É importante lembrar que a crítica é ao relatório, não à pessoa
  • A equipe do curl é até bem generosa, e os ataques no Reddit não têm relação com a comunidade oficial
  • Ironicamente, até as reações nesta thread tratam de uma experiência “não reproduzível”

• Para resolver o problema da Eternal September e das contribuições de baixa qualidade criadas por LLM, acho que pode ser necessário justamente aumentar o atrito de entrada (friction)
  Por exemplo, exigir que a primeira contribuição seja enviada como relatório em cartão-postal com QR code

  • Mas esse atrito pode não funcionar, porque muitas vezes spammers de contribuições aguentam melhor esse tipo de barreira do que contribuidores legítimos

• Se um projeto começa a se afogar em PRs cheios de emoji e erros, fica difícil o modelo Bazaar continuar funcionando

  • Isso me faz lembrar da Lei de Brandolini
    O excesso de informação não verificada não é um problema só do open source, mas da sociedade como um todo
    A cultura ainda não desenvolveu um sistema imunológico contra informação falsa

• Isso me lembra a época em que o The Pirate Bay publicava os e-mails de ameaça jurídica da MPAA
  Dá para ver esse histórico na página de respostas legais do TPB (Web Archive)
  O método deles não era exatamente eficaz, mas acabou ficando como uma espécie de símbolo de resistência

• Em um projeto open source famoso mantido por um amigo, universitários chineses enviam relatórios falsos de vulnerabilidades de segurança como tarefa acadêmica
  A maioria não pode ser reproduzida e só desperdiça o tempo dos mantenedores
  Além disso, por diferenças de configuração entre distribuições, vulnerabilidades reais às vezes surgem na configuração do pacote, e não no código upstream
  No subreddit do Kryptos K4 também está cheio de posts de “resolvi!” feitos por LLM, e na primeira infração a pessoa já leva ban
  Preocupa ver a cola em tarefas com IA se espalhando agora para todas as áreas

  • Como humanos, não devemos perder a alegria de aprender e crescer
    Por mais que a IA avance, o valor do aprendizado próprio é insubstituível
  • No Kryptos K4, mesmo sabendo todos os dados, o LLM não consegue ter nenhuma ideia nova
    No fim, LLM é menos pensamento criativo e mais uma ferramenta de autocompletar turbinada
  • Na China, é comum estudantes de medicina não escreverem seus próprios artigos e poluírem periódicos acadêmicos com textos encomendados a terceiros
  • No fim, a fraude acadêmica chega ao mercado, e enquanto houver incentivo financeiro, isso não vai parar

• Acho que o GitHub deveria dar aos usuários algum score de confiança ou sistema de reputação

  • Mas como o GitHub agora faz parte da divisão de IA (Microsoft CoreAI), é bem possível que acabe incentivando esse tipo de comportamento
    Artigo relacionado: matéria da GeekWire
  • A ideia de a Microsoft dar uma pontuação social para desenvolvedores é horrível
  • Talvez fosse melhor anonimizar os usuários para reduzir o incentivo à busca por fama
  • Plataformas como a HackerOne também têm sistemas de reputação, mas os relatórios de baixa qualidade continuam em excesso
    No fim, empresas acabam pagando por serviços de triagem intermediária
    Nesse processo, quem responde primeiro às vezes nem é um especialista de verdade, o que faz relatórios legítimos serem tratados com atraso
    A situação atual é uma estrutura ruim para todo mundo e está piorando cada vez mais