A pressão
(daniel.haxx.se)- A manutenção do curl se tornou um trabalho em tempo integral que combina utilidade pública, desafio de engenharia e metas de qualidade, e vem consumindo cerca de 50 horas por semana
- O curl é uma biblioteca e ferramenta de transferência com uma base instalada de cerca de 30 bilhões, e há uma grande pressão para evitar que falhas de segurança se espalhem para os usuários
- O volume atual de relatórios de segurança é 4 a 5 vezes maior do que em 2024 e o dobro do nível de 2025, com média de mais de um caso por dia, exigindo tratamento imediato
- O trabalho de segurança inclui validar alegações, avaliar gravidade, escrever patches, identificar quando o problema foi introduzido, redigir advisories e se comunicar com pesquisadores e com a equipe de segurança
- Até o próximo lançamento, já há 12 vulnerabilidades confirmadas na fila, e a pressão sem precedentes expõe os limites de financiamento e de suporte de pessoal
Responsabilidade com o curl e manutenção de longo prazo
- O trabalho em open source não é feito por dinheiro nem por uma vida glamourosa, mas continua por causa do significado social, do interesse público e do desafio de engenharia de fazer algo funcionar para todos
- O trabalho com curl se tornou em tempo integral desde 2019, normalmente consumindo cerca de 50 horas por semana, incluindo dias, noites, semana e fins de semana
- O objetivo do curl é ser a melhor biblioteca e ferramenta de transferência possível e se tornar um projeto de ponta em qualidade, desempenho e segurança no open source
- O curl não é um projeto de uma pessoa só; sem os membros da equipe, o curl atual não existiria, mas muita gente ainda o associa fortemente a Daniel Stenberg como indivíduo
- As críticas ao curl são sentidas como críticas a decisões e escolhas que ele próprio apoiou ou tomou diretamente, e o curl se tornou um projeto pessoal que mudou sua vida para sempre
- No fim de 2026, o projeto curl completará 30 anos, e o número de instalações de curl no mundo é estimado em cerca de 30 bilhões
Mudanças no cenário dos relatórios de segurança
- Nos últimos anos, o cenário de relatórios de segurança do curl evoluiu de reclamações sobre LLMs idiotas para relatórios gerados por lixo de IA, o fim do bug bounty e o caos de alta qualidade que começou por volta de março de 2026
- Sempre que grandes falhas de segurança se repetem em produtos de internet, infraestrutura de software e open source, aumenta a pressão pelo fato de o curl estar em todo lugar, e de algo assim não poder acontecer com o curl nem com seus usuários
- O projeto curl vem adicionando mais revisões, testes e diretrizes, reduzindo aos poucos a chance de defeitos escaparem ou afundarem o projeto
Alto nível de verificação e riscos remanescentes
- Depois do episódio em que o Mythos encontrou apenas um problema de baixa gravidade na primeira varredura, voltou a se repetir a avaliação de que o curl é um dos códigos mais revisados, fuzzados e verificados que se pode imaginar
- Esse estado não é fruto de acaso nem de sorte, mas do resultado de décadas de trabalho persistente, atenção aos detalhes e melhoria iterativa sem fim
- Mesmo com tanta revisão e verificação, isso não significa ausência de bugs ou problemas de segurança; o curl é composto por centenas de milhares de linhas de código C que executam rede altamente paralela em vários protocolos, sistemas operacionais e arquiteturas de CPU
- Sempre que um problema é descoberto, repete-se o processo de corrigi-lo e liberar um patch
- A base instalada global de cerca de 30 bilhões significa que o curl provavelmente está presente várias vezes em celulares, tablets, carros, TVs, impressoras, consoles e eletrodomésticos de cozinha
- No passado, projetos que colocaram o mundo em chamas por algum tempo com bugs graves receberam atenção, e alguns conseguiram financiamento e equipe para contratar vários engenheiros em tempo integral
Volume inédito de relatórios de segurança
- O ritmo atual de entrada de relatórios de segurança é 4 a 5 vezes maior do que em 2024, o dobro de 2025, e chega em média a mais de um relatório por dia
- A qualidade dos relatórios é muito mais alta do que antes, e eles geralmente são muito detalhados e extensos
- Como os relatórios continuam chegando, é preciso tratá-los sempre que possível assim que chegam; se o processamento não acompanhar o ritmo de entrada, a lista de possíveis problemas de segurança continuará crescendo
- Uma lista de possíveis problemas de segurança fora de controle gera carga mental
- No momento, a maior parte do tempo está sendo gasta no tratamento da lista de issues de segurança reportadas no HackerOne
- As principais tarefas são validar alegações, avaliar gravidade, escrever patches, identificar quando o bug foi introduzido, entender a vulnerabilidade, redigir advisories de segurança detalhados e se comunicar com pesquisadores de segurança e com a equipe de segurança do curl
Pressão sobre a saúde e a equipe
- Pela primeira vez, a esposa demonstrou preocupação com as horas de trabalho e com o desequilíbrio entre vida e trabalho, e pessoas ao redor também se preocupam com como lidar com esse grande volume e com a possibilidade de esgotamento
- A preocupação com os membros da equipe também aumentou, e pode ser necessário reduzir o tempo de trabalho para conseguir algum respiro em breve
- A situação atual é uma pressão que nem o projeto curl nem os integrantes da equipe de segurança haviam experimentado antes
- Lidar com issues de segurança é uma tarefa de prioridade tão alta que passa à frente de todo o resto no projeto, e não é ignorada por senso de responsabilidade, consciência e orgulho pelo trabalho
- Como o curl é um software distribuído em dispositivos no mundo inteiro, há um forte senso de obrigação de corrigir os problemas de segurança nele
- Restando cerca de metade do ciclo até o lançamento previsto, já existem 12 vulnerabilidades confirmadas, o que significa 12 divulgações de CVE aguardando publicação
- Isso é um novo recorde do projeto e significa que 2026 chegará a 30 CVEs públicas antes mesmo de passar da metade do ano
- Se essa tendência continuar, o total de CVEs públicas do curl em 2026 deve ser pelo menos o dobro disso
Suporte necessário e limitações estruturais
- No curto prazo, já há trabalho demais a ser processado, então é tarde para receber ajuda imediata
- Se mais empresas que usam e dependem do curl ou do libcurl em softwares e serviços comerciais oferecerem financiamento, será possível pagar mais desenvolvedores para dividir a carga de trabalho
- Contratos de suporte, pelos quais o empregador paga o custo, também são um caminho possível de apoio
- Já existem clientes que fornecem esse tipo de apoio, e por isso alguns integrantes conseguem trabalhar com curl em tempo integral
- Ainda assim, não há expectativa de que uma mudança significativa aconteça em breve nessa área, e mesmo em uma situação sem precedentes e numa fase mais difícil, é provável que no fim o projeto tenha de atravessar a tempestade por conta própria
- O projeto curl não pertence a uma empresa nem faz parte de nenhuma organização guarda-chuva
- Essa estrutura às vezes leva à falta de recursos, mas ao mesmo tempo oferece o máximo de liberdade e flexibilidade
- O padrão que orienta as ações do projeto é tornar o curl o melhor possível para o mundo e para seus usuários
O lado positivo e o estado atual
- Corrigir bugs e problemas é, por si só, algo bom, e cada problema reportado significa uma issue a mais corrigida
- Quanto mais relatórios chegam, melhor o curl se torna como produto
- Nos últimos anos, todas as vulnerabilidades encontradas no curl foram avaliadas com severidade LOW ou MEDIUM, e vulnerabilidades muito graves quase não apareceram
- Isso não significa que não possa surgir um HIGH novamente no futuro, mas pelo menos continua sendo algo raro
- O CVE de alta gravidade mais recente do curl foi o CVE-2023-38545, divulgado em outubro de 2023
- No momento, a equipe do curl está sob pressão e, às vezes, pode responder mais devagar
1 comentários
Comentários do Lobste.rs
Espero que Daniel e os outros consigam passar bem por essa situação difícil sem grandes impactos na saúde ou na família
Dito isso, vai ser bem interessante ver como isso se desenrola. Não é a primeira vez que uma nova forma de análise automatizada encontra de repente muitas vulnerabilidades em vários projetos FOSS, e agora parece algo semelhante ao que aconteceu quando o fuzzing gray-box surgiu nos anos 2010. Vejo três desdobramentos possíveis: A) os desenvolvedores incorporam LLMs ao fluxo de pesquisa em segurança, o número de novas vulnerabilidades encontradas por LLM cai bastante, e continuam sendo encontradas vulnerabilidades que LLMs não alcançam, como no cenário dos fuzzers. B) semelhante ao A, mas depois que os LLMs varrem tudo, a descoberta de vulnerabilidades praticamente para, no cenário em que “os LLMs resolvem a pesquisa em segurança”. C) continuam sendo encontradas vulnerabilidades em alta proporção em projetos grandes como o curl, e o número de bugs em projetos com centenas de milhares de linhas de código é praticamente infinito, no cenário da “vingança de Tony Hoare”
Só pode existir um número finito de bugs de segurança em um snapshot de uma codebase específica. Quando o espaço de busca por bugs de segurança se esgota, a enxurrada diminui, e depois devem restar aos poucos os bugs vindos de merges de código, novos test harnesses ou melhorias no modelo
Sobre o cenário C no projeto curl, acho que os bugs encontrados tiveram baixa gravidade porque o nível prévio de testes de segurança e das técnicas tradicionais de descoberta de bugs já era alto. Isso mostra que o investimento contínuo em descoberta de bugs continua compensando no longo prazo. Vale hoje e vale para qualquer método de descoberta que surja no futuro
Para citar Marcus Hutchins, é mais algo como: “a descoberta de bugs nunca foi o gargalo; o gargalo foi a decisão das organizações de não investir em pesquisadores de segurança”. Os LLMs só tornaram esse investimento mais barato, e as organizações sempre puderam investir mais para encontrar mais bugs. No fim, é uma decisão de política
As empresas que criam tecnologia de LLM estão destruindo não só o mundo natural, mas também o mundo do software. Com o preço do hardware disparando, até a computação pessoal está ameaçada, e o mesmo vale para desenvolvedores de código aberto bem-intencionados que criam porque querem criar
Parece haver dinheiro infinito para diminuir e quebrar projetos de código aberto administrados por comunidades, mas nenhum dinheiro para lidar com as consequências disso, o que é interessante
Acho que isso prova que o Zig estava certo. CVEs encontrados por LLM simplesmente não devem ser tratados; quem quiser que cuide disso
Sei que esse não é exatamente o ponto central, mas o problema dos CVEs via LLM é que qualquer outra pessoa usando a mesma ferramenta provavelmente consegue encontrar a mesma coisa. Se um problema realmente grave for encontrado, isso significa que mais gente pode usar isso para criar algo malicioso
Claro, isso não quer dizer que o mesmo se aplique igualmente aos inúmeros problemas de baixa gravidade ou não relacionados à segurança que chegam ao curl. Ainda assim, é preciso avaliar de fato quais questões têm alta prioridade, e aí voltamos ao passo 1
O Zig ainda está em desenvolvimento ativo e, cada vez que consolida recursos como compilação incremental ou I/O assíncrono, há uma grande chance de introduzir novos bugs, ao mesmo tempo em que remove bugs causados por implementações anteriores incompletas
Nesta fase do desenvolvimento, se alguém rodasse algo como Mythos no Zig com a ideia de “encontrar todos os bugs e não cometer erros”, sairia um volume enorme de relatórios, mas é bem possível que isso tudo fosse, na prática, inútil para nós. Hoje, o principal valor dos relatórios de bug é sinalizar que há um usuário bloqueado em um caso de uso específico e que, se decidirmos priorizar isso, podemos destravar esse usuário
Isso não quer dizer que esse estado vá durar para sempre. Muitos recursos importantes do compilador estão sendo alinhados e, quando estabilizarem, encontrar e corrigir todos os bugs passará a ser a prioridade máxima. Nesse ponto, o fato de um bug ser conhecido vai importar independentemente de como ele foi descoberto, mas esse problema será tratado quando chegarmos lá
Enquanto isso, a política é simplesmente proibir LLMs
Entendo proibir contribuições de LLM, mas não concordo. Uma vulnerabilidade de segurança continua sendo uma vulnerabilidade, independentemente de como foi descoberta
Acho que o jeito como Daniel está lidando com isso é o melhor. Corrigir os bugs que dá para corrigir para deixar os usuários mais seguros, e pedir apoio deixando claro o custo disso. É improvável que ele leia isto, mas eu também apoiaria e recomendaria limitar a carga de trabalho para priorizar a saúde física e mental. A maior parte do mundo vai entender; só uma minoria deve reclamar
Parece que faltam duas coisas centrais aqui. 1) Nem a empresa de LLM nem o Project Zero colocaram esses bugs de segurança no código. 2) Corrigir bugs de segurança não é para a empresa de LLM nem para o Project Zero, e sim para os usuários. Quando bugs de segurança são explorados, quem sofre são os usuários
No caso específico de bugs encontrados por LLM, já há sinais de que outras pessoas usando o mesmo LLM em vários projetos de código aberto estão enviando relatórios duplicados. Portanto, se os defensores deixarem isso de lado, é preciso presumir que os atacantes também saberão desses bugs encontrados por LLM
“Tenho inveja dos projetos que distribuíram bugs terríveis que colocaram o mundo em chamas por um tempo. Eles receberam atenção e alguns conseguiram financiamento e poder financeiro para ter equipe e contratar vários engenheiros em tempo integral. Às vezes penso que teria sido melhor se nós também tivéssemos tido um desses”
Esse tipo de coisa acontece em muitos locais de trabalho também. Equipes que fracassam recebem mais gente, enquanto equipes que vão bem têm de fazer mais com menos pessoas justamente porque nada terrível aconteceu
Não sei se isso serviria para um projeto como o curl, mas será que ajudaria fazer um congelamento de funcionalidades por um período e focar apenas nos relatórios de bugs/CVEs que estão entrando?
Se o conjunto de funcionalidades for fixo, o número de bugs/CVEs potenciais é finito, e parece que, ao corrigi-los, isso se aproximaria de zero
De qualquer forma, desejo sorte a eles. Não deve ser fácil manter um software tão importante
Sobre a satisfação dos desenvolvedores, os efeitos são, nessa ordem: aumento, manutenção, redução
Congelamento de funcionalidades é uma ferramenta excelente para concluir bem um release, mas não é uma boa ferramenta para aliviar a pressão sobre desenvolvedores que trabalham definindo a própria direção