Bitcoin Core encerra embargo de um ano para bugs facilmente detectáveis

O Bitcoin Core está encerrando a espera de um ano por patches de segurança que um modelo de linguagem pode encontrar novamente em um único prompt. Uma alteração na política de divulgação de segurança do projeto, integrada em 22 de outubro, cria uma classe de vulnerabilidade “fácil de descobrir” e instrui os mantenedores a lançar uma versão pontual e um aviso público “o mais rápido possível” — contornando o embargo padrão que mantém um bug de gravidade média ou alta em segredo por aproximadamente um ano.

O gatilho é direto. Os mantenedores estão recebendo mais relatos de bugs que continuam sendo redescobertos, porque os modelos de linguagem reduziram o esforço necessário para encontrá-los. Antoine Poinsot, contribuidor do Bitcoin Core na Chaincode Labs, anunciou a variação na lista de email de desenvolvimento do Bitcoin no mesmo dia em que o pull request foi mesclado.

“Recentemente, experimentamos um aumento no número de relatos de vulnerabilidades de segurança que podem ser facilmente (re)descobertas”, escreveu Poinsot. “Isso ocorre em grande parte porque os LLMs reduziram drasticamente a barreira para encontrar certas classes de problemas ou identificar correções ocultas.”

A política anterior do Bitcoin Core vinculava o momento da divulgação à gravidade. Bugs de baixa gravidade eram tornados públicos duas semanas após o lançamento da próxima versão principal. Bugs de média e alta gravidade permaneciam privados até duas semanas após a última versão afetada atingir o fim da vida útil — uma janela que a própria política descreve como “aproximadamente um ano após a primeira liberação de uma versão principal contendo a correção”.

Aquele cronograma existia por uma razão. O Bitcoin Core é a implementação de referência que executa a maioria dos nodes do Bitcoin, e os operadores de nodes atualizam lentamente. Um longo embargo foi planejado para dar à rede tempo para corrigir antes que os detalhes fossem tornados públicos. A compensação foi que as correções geralmente não eram retroativas, então um operador em uma versão mais antiga aguardava a próxima versão principal, que o projeto visa lançar aproximadamente a cada seis meses.

A cautela é estrutural, não acidental. Alterações de consenso, como a atualização Taproot do bitcoin, seguem um caminho lento e conservador precisamente para que os operadores possam adotá-las conforme seu próprio cronograma.

“Devido à natureza do nosso projeto, aliada a uma cultura de atualização lenta, nossa política de segurança prefere um período de embargo mais longo”, escreveu Poinsot. “Isso geralmente significa que correções de segurança não podem ser retroportadas e só se tornam disponíveis para os usuários junto com a próxima versão principal.”

A IA quebra esse compromisso. Se um bug pode ser redescoberto com uma varredura trivial de um LLM, escondê-lo não traz nenhum benefício, pois a falha já está ao alcance de qualquer pessoa que tenha um chatbot. “Para esses problemas que são fáceis de encontrar, esse é o compromisso errado. O período de embargo pouco alcança, mas atrasa a disponibilidade de uma versão corrigida”, escreveu Poinsot.

Sob a política revisada, o cronômetro de divulgação agora possui uma terceira configuração. Uma vulnerabilidade pode ser marcada como “fácil de descobrir” durante a triagem — definida como aquela que “pode ser descoberta com esforço mínimo, como por meio de um simples prompt de LLM”. O rótulo não se limita a bugs encontrados por IA: ele indica o quão pouco esforço é necessário para a rediscover, e não qual ferramenta realizou a descoberta.

Para esses bugs, a resposta varia em todos os eixos. Em vez de uma única correção ser incluída na próxima versão principal, os mantenedores farão backport de uma correção para cada versão principal atualmente mantida — três ramos sob a regra do Bitcoin Core de suportar suas três últimas versões — e lançarão versões pontuais o mais rápido possível. Um aviso de segurança será publicado junto com o software corrigido.

A escala de gravidade ainda governa tudo o mais. Bugs de baixa gravidade permanecem no cronograma de duas semanas. Médios e altos permanecem no cronograma aproximado de um ano. Bugs críticos — aqueles que podem roubar moedas no nível do protocolo, inflacionar a oferta ou dividir permanentemente a cadeia — permanecem fora da política padrão e são tratados caso a caso, como sempre foram.

Essa isenção existe por um bom motivo. Na história do Bitcoin Core, o bug de inflação divulgado como CVE-2018-17144 em setembro de 2018 foi o tipo de falha que justificava tratamento especial: poderia ter permitido a criação de moedas fora do cronograma de emissão. A nova rota "fácil de descobrir" não afeta esse nível — um bug crítico ainda receberá uma resposta ad hoc moldada conforme o risco para toda a rede.

A variação é mais fácil de ler como uma redução na janela de divulgação. Um bug de gravidade média corrigido hoje normalmente permaneceria privado por cerca de 52 semanas, divulgado apenas duas semanas após a última versão afetada atingir o fim da vida útil. O mesmo bug, uma vez sinalizado como facilmente descobrível, é lançado como uma versão pontual “o mais rápido possível” junto com seu aviso. Essa é a diferença entre um ano e, na própria formulação dos mantenedores, o tempo necessário para escrever, revisar e testar um patch direcionado.

O compromisso de backport é a outra metade. Antes da mudança, um conserto geralmente não chegava aos usuários em uma ramificação antiga mantida; ele chegava com a próxima versão principal. Agora, um operador em uma versão antiga suportada pode aplicar uma versão pontual direcionada sem adotar todos os recursos e alterações de comportamento da versão principal mais recente. Para uma rede onde as atualizações são lentas e deliberadas, isso representa uma mudança significativa na velocidade com que um patch pode realmente ser implementado.

A rota mais rápida tem um custo, e Poinsot disse isso claramente no pull request. “Isso é particularmente importante pois, sob esta política, as mitigações não terão tanto ‘tempo de amadurecimento’ nas branches de desenvolvimento antes de serem liberadas para os usuários”, ele escreveu. Um conserto que é lançado em dias passa menos tempo em revisão e teste do que um que ficou por meses.

A discussão também se dividiu sobre se a divulgação deveria ocorrer ainda mais rapidamente. Alguns contribuidores argumentaram que abrir uma solicitação de correção pode, por si só, alertar atacantes, pois é barato monitorar automaticamente o repositório, portanto, a divulgação pode precisar ocorrer não mais tarde que o patch, ou antes dele, com orientações de mitigação. Um outro contribuidor propôs lançar correções com um aviso discricionário ou atrasado. Poinsot rejeitou isso, escrevendo que alertar usuários sem detalhes poderia desencadear uma migração apressada entre operadores que nunca foram afetados.

A exchange importa porque mostra que a nova política é um caminho intermediário deliberado, não um óbvio. O texto combinado mantém o aviso simultâneo à correção e mantém todos os detalhes, em vez de um aviso vago.

Nenhuma vulnerabilidade foi inserida na nova classe ainda, portanto, trata-se de uma mudança de processo, não da divulgação de uma falha ativa. O primeiro teste real ocorrerá quando os mantenedores sinalizarem algo “fácil de descobrir” durante a triagem e lançarem versões de correção em todas as ramificações mantidas com um aviso simultâneo.

O sinal mais amplo é que a caça a bugs assistida por IA já forçou o ecossistema Bitcoin a se mover. O Core Lightning informou aos operadores de nodes no início deste ano para atualizar ou desconectar após relatórios de vulnerabilidades gerados por IA provarem ser corretos. A mudança de política do Bitcoin Core é a implementação de referência fazendo o mesmo cálculo na camada base do protocolo: quando a rediscover é barata, o sigilo compra pouco, e a única coisa que um embargo prolongado atrasa é a liberação fixa.

Para operadores de nodes, nada muda hoje. O ritmo de atualização permanece o mesmo. A diferença ocorre na próxima vez que um bug for considerado facilmente detectável, quando um patch e seu aviso forem lançados juntos com menos aviso prévio do que a rede já teve.