Turso encerra programa de bug bounty
(turso.tech)- A Turso encerrou, após cerca de 1 ano, o bug bounty que pagava US$ 1.000 por bugs que comprovassem corrupção de dados
- Com a recompensa em dinheiro, houve um grande volume de PRs de baixa qualidade gerados por IA, e os mantenedores passaram dias gastando tempo para fechá-los
- No início, 5 pessoas receberam recompensa, e algumas contribuições levaram a melhorias no simulador e à descoberta de mais de 10 bugs no SQLite
- A Turso chegou a usar um sistema de aval para fechar automaticamente PRs suspeitos, mas bots continuaram abrindo issues pedindo revisão manual e reenviando PRs semelhantes
- Para manter as contribuições abertas, a Turso escolheu remover o incentivo financeiro em vez de fechar o sistema
Por que a Turso interrompeu o bug bounty
- A Turso pagou por quase 1 ano US$ 1.000 por bugs que pudessem ser comprovadamente ligados à corrupção de dados, mas agora encerrou o programa
- Depois que a recompensa em dinheiro foi criada, o repositório da Turso passou a receber uma enxurrada de PRs de baixa qualidade gerados por IA, e os mantenedores precisavam passar dias dedicando a maior parte do tempo a fechar esse tipo de PR
- A Turso quer continuar sendo um projeto aberto a contribuições, mas considera que pagar por um tipo específico de bug tornou a operação de contribuições abertas quase inviável
- A decisão foi publicada com a percepção de que todos precisam aprender juntos a construir a governança do open source nesta nova era
Contexto do lançamento do programa
- A Turso está reimplementando o SQLite, conhecido como um dos softwares mais confiáveis do mundo, e por isso precisa de um padrão de confiabilidade igualmente alto
- A Turso opera vários sistemas de teste para igualar ou superar o nível de confiabilidade do SQLite
- simulador determinístico nativo
- vários fuzzers
- mecanismo de teste diferencial baseado em oráculo comparando com o SQLite
- simulador de concorrência
- execução extensiva na Antithesis
- A infraestrutura de testes também é software e, no fim das contas, não é perfeita; ela só consegue encontrar bugs dentro das combinações que seus geradores realmente produzem
- Por exemplo, se um fuzzer não criar índices, fica difícil encontrar bugs relacionados a índices, mesmo que outras partes do sistema sejam fortemente estressadas
- A Turso encontrou um bug que só aparecia quando o banco de dados passava de 1 GB, mas como o sistema injetava falhas de forma agressiva em cada execução, o banco não chegava a crescer até esse tamanho e o bug escapava do simulador
- Conteúdo relacionado: Uma aventura escrevendo sistemas compatíveis
- A vantagem dos testes automatizados é que, mesmo quando um bug escapa uma vez, ao melhorar o gerador de testes é possível eliminar uma categoria inteira de bugs
- O bug bounty servia para mostrar a confiança da Turso na sua metodologia de testes e, ao mesmo tempo, recompensar quem encontrasse áreas que o simulador não cobria bem
- O plano inicial era pagar US$ 1.000 por bugs de corrupção de dados até o lançamento da Turso 1.0 e, depois da 1.0, aumentar gradualmente tanto o valor quanto o escopo das recompensas
Efeito antes do aumento das submissões ruins geradas por IA
- No começo do programa, 5 pessoas receberam recompensa no total, e contribuíram de forma significativa para o projeto
- Alperen foi um dos principais contribuidores do simulador da Turso e conhecia bem os pontos que podiam ser melhorados
- Mikael usou LLMs de forma criativa para encontrar pontos que o simulador não alcançava e depois acabou sendo contratado pela Turso
- Pavan Nambi combinou o simulador com métodos formais e encontrou não só bugs da Turso, mas também mais de 10 bugs no próprio SQLite
A carga operacional criada pelas submissões geradas por IA
- O critério de submissão que a Turso queria não era apenas apontar um bug, mas expandir o simulador para comprovar um bug de corrupção de dados
- Graças a essa exigência, PRs mal-intencionados em busca de recompensa eram raros, e também não havia tantos bugs reais de corrupção de dados
- Depois disso, surgiu em massa um tipo de submissão que instruía LLMs a encontrar bugs na Turso e receber a recompensa
- Quando recebem esse tipo de instrução, LLMs produzem algum tipo de saída, mas isso não significa que o conteúdo seja válido
Exemplos representativos de submissões de baixa qualidade
-
PR que corrompia manualmente o cabeçalho do banco de dados
- O PR #6257 injetava manualmente bytes de lixo no cabeçalho do banco de dados e então alegava que o banco havia sido corrompido
- Mesmo depois de o mantenedor apontar que esse era um resultado óbvio, o autor ou bot continuou com longas respostas no estilo de LLM
-
Submissão que inseria acesso out-of-bounds diretamente no código-fonte
- Outra submissão adicionava manualmente acesso a array fora dos limites no código-fonte para corromper o banco de dados
- Issue relacionada: tursodatabase/turso#5508
-
PR que tratava a execução de SQL como vulnerabilidade
- O PR #4322 vinha cheio de tabelas, marcas de verificação verdes e travessões, alegando ter encontrado uma vulnerabilidade crítica por permitir a execução de instruções SQL arbitrárias
- A Turso não considera vulnerabilidade o fato de um banco de dados SQL permitir a execução de instruções SQL
-
PR que interpretava errado o recurso de escrita concorrente da Turso
- O PR #6874 habilitava a escrita concorrente, um dos diferenciais da Turso, e então mostrava que o SQLite não conseguia abrir o arquivo até que o modo de journal fosse revertido para WAL, desativando a escrita concorrente
- Isso era simplesmente o sistema funcionando como foi projetado
-
Submissão de intenção difícil de entender
- Outra submissão tinha um conteúdo difícil de interpretar em termos de objetivo
- O mantenedor Mikael concluiu que o autor havia visto o anúncio da recompensa e direcionado uma ferramenta de geração por IA contra a Turso
Última resposta: sistema de aval
- Como última tentativa de restaurar a ordem, a Turso projetou e implementou um sistema de aval (vouching)
- Ele fechava automaticamente submissões suspeitas de terem vindo de bots, e por algum tempo funcionou até certo ponto
- Depois, os bots passaram a abrir issues pedindo revisão manual, questionando o motivo de seus PRs terem sido fechados
- Em vários casos, ao fechar um PR, o mesmo usuário ou outro usuário voltava a abrir imediatamente um PR idêntico ou muito parecido
O conflito entre contribuições abertas e incentivos financeiros
- Quem produz submissões de baixa qualidade gasta cerca de 1 minuto para gerá-las, mas a Turso precisa gastar horas para ler, entender e responder
- Essas submissões podem ser geradas praticamente em velocidade infinita
- É possível criar sistemas automatizados de triagem, mas quando há uma recompensa financeira relevante, a IA tem ainda mais incentivo para continuar discutindo e reabrindo PRs semelhantes
- A Turso valoriza a comunidade de contribuidores open source e continuará fortalecendo-a, mas no momento considera que nenhuma forma de incentivo financeiro funciona bem em um sistema aberto
- As opções são fechar o sistema ou remover o incentivo, e a Turso escolheu a segunda por enquanto
1 comentários
Opiniões do Hacker News
Isso mostra que o gargalo não está em escrever código, mas em ler e entender o código
Antigamente também sempre havia em algum time um engenheiro “produtivo” que abria PRs enormes cheios de refatorações em larga escala, independentemente de serem necessárias ou não. Isso já acontecia antes mesmo de alguém imaginar que redes neurais poderiam gerar tanto código assim
O resultado dessa “produtividade” não era acelerar o time, mas quase paralisá-lo. Ou todo mundo gastava o tempo revisando o PR com cuidado, ou davam um LGTM superficial e depois explodia em produção, obrigando todos a voltar para a prancheta. Além disso, por causa da “produtividade” dessa pessoa, a estrutura do projeto mudava rápido demais, e a única pessoa que sabia claramente onde ficava cada coisa era justamente aquela “pessoa muito inteligente, talentosa, produtiva e leal aos objetivos da empresa”
“Em quase toda organização de desenvolvimento de software, existe pelo menos um desenvolvedor que leva a programação tática ao extremo. É o tornado tático. O tornado tático é um programador prolífico, que produz código muito mais rápido que os outros, mas trabalha de forma totalmente tática. Quando se trata de implementar rapidamente uma funcionalidade, ninguém o supera. Em algumas organizações, gestores tratam o tornado tático como um herói. Mas o tornado tático deixa um rastro de destruição. Os engenheiros que depois precisam trabalhar nesse código muitas vezes não o veem como herói. Em geral, são outros engenheiros que precisam limpar a bagunça deixada pelo tornado tático, e por isso esses verdadeiros heróis acabam parecendo avançar mais devagar que o tornado tático.”
Além disso, quanto mais código gerado por IA houver, menos gente de fato vai entender esse código
Ainda assim, se os testes de regressão e o linter estiverem bem montados, e você souber que o código funciona e não está uma porcaria, a revisão deveria focar mais na qualidade geral em alto nível do que em examinar a precisão de cada caractere. Claro, a revisão em si continuou sendo dolorosa
Naturalmente, acabei lendo e entendendo mais código do que escrevendo, e às vezes meu número de linhas escritas era negativo, do que eu até me orgulhava
Agora, graças à IA, escrevo ainda menos código, e desisti do sonho de tirar satisfação disso. A habilidade de entender rapidamente grandes volumes de código de origem suspeita, seja feito por máquina ou por pessoa, espero que continue valiosa até eu me aposentar, especialmente com ajuda de IA. O que vocês acham?
Nós não escrevemos só código para a máquina executar, mas também código para pessoas lerem. Revisão de código, depuração e mudanças futuras envolvem alguém lendo e entendendo o código escrito por outra pessoa. E até existir uma IA que possa ser responsabilizada por suas ações, não dá para delegar esse entendimento a ela
É um ótimo momento para mencionar este excelente projeto, um repositório honeypot para atrair bots
https://github.com/UnsafeLabs/Bounty-Hunters
O ranking correspondente está aqui
https://clankers-leaderboard.pages.dev
Fico curioso para saber o que acontece se IAs treinarem nesses repositórios e nas atividades dentro deles. Os relatórios de bug nas issues são problemas reais que podem ser corrigidos ou delírios inventados?
Só que tem grande chance de em breve entrar em uma blocklist de bots de IA
Fechar o programa é totalmente razoável. Mas há outras opções. Dá para fazer o autor do envio pagar uma pequena taxa e receber o dinheiro de volta caso um bug real seja encontrado
Não importa se o programa realmente paga recompensas. Se um único relatório for encerrado indevidamente, essa história vai se repetir para sempre
Nesses casos, hoje você já perde tempo; no futuro, passaria a perder dinheiro também
Principalmente em empresas pequenas, não dá para saber antes do envio como a empresa vai reagir
Talvez fosse possível exigir a execução completa da suíte de testes do simulador antes do envio? Seria uma boa verificação de que o autor não quebrou o simulador e, de quebra, poderia gerar um artefato de prova de trabalho. Não sei se isso é viável, porque não entendo muito da parte de segurança
Passei mais de um ano tentando fazer o TursoDB carregar um único arquivo, mas não consegui: https://github.com/ClickHouse/ClickBench/issues/336
Fico imaginando como estaria o Hacktoberfest hoje se ainda desse camiseta para todo mundo. Provavelmente não haveria algodão suficiente no mundo
Não deveria ser responsabilidade de mantenedores individuais impedir isso; GitHub e GitLab é que deveriam barrar essas contas antes mesmo de elas chegarem ao ponto de poder abrir PRs. Isso é essencialmente spam
Veja o usuário que fez o PR mencionado primeiro no texto: https://github.com/Samuelsills. Contas assim não deveriam nem chegar perto de abrir PRs em repositórios populares
Posso estar fazendo uma pergunta boba por não conhecer bem a área, mas se fosse exigida no final a execução completa dos testes do simulador para verificar que a mudança enviada não quebrou funcionalidades existentes, isso poderia servir como prova de trabalho?
Em vez de um programa de bounty, e se criassem uma espécie de mercado de previsão verdadeiro/falso
A ideia seria apostar publicamente na resposta, cada um usando seus próprios tokens para validar a substância do relatório e então comprar a aposta. Se a maioria achar que é falso, o operador ganha; se a maioria achar que é real, o operador paga
Estou brincando, mas talvez não totalmente
Alguém já usou o Turso em produção? É uma implementação compatível com SQLite reescrita em Rust, com recursos como suporte a múltiplos escritores, e ao contrário do SQLite também é aberta a contribuições externas
Estou pensando em usar em um app full-stack em Rust, porque tudo funciona com cargo e não preciso trazer o SQLite separadamente
O Turso também oferece banco de dados como serviço com um plano gratuito bem generoso, e esse foi o principal motivo de eu ter usado
https://x.com/doodlestein/status/2052910351474209258
Não daria para contra-atacar do mesmo jeito e implantar seu próprio bot de IA para fazer uma triagem prévia dos PRs?
“É possível configurar sistemas automatizados para impedir isso, mas quando existe valor financeiro grande demais para ser ignorado, o incentivo para fazer IAs continuarem discutindo e reabrindo o mesmo PR é forte demais”
Do ponto de vista de quem está de fora, é um problema interessante. De quantos desses pedidos de bots os agentes estarão usando o Turso no próprio backend?