Cerramos el programa de bug bounty
(turso.tech)- Turso operó durante casi un año un bug bounty que pagaba 1,000 dólares por demostrar bugs de corrupción de datos, y ahora lo cierra
- Tras introducir una recompensa monetaria, llegaron en masa PR de baja calidad generados por IA, y los mantenedores pasaron días enteros cerrándolos
- Al inicio recompensaron a 5 personas, y algunas contribuciones llevaron a mejoras del simulador y al hallazgo de más de 10 bugs en SQLite
- Turso implementó un sistema de avales para cerrar automáticamente PR sospechosos, pero los bots siguieron abriendo issues para pedir revisión manual y reenviando PR similares
- Para mantener las contribuciones abiertas, Turso eligió eliminar el incentivo económico en lugar de cerrar el sistema
Por qué Turso detiene su bug bounty
- Turso pagó durante casi un año 1,000 dólares por bugs que demostraran poder causar corrupción de datos, pero ahora da por terminado el programa
- Después de agregar una recompensa monetaria, el repositorio de Turso se llenó de PR de baja calidad generados por IA, y los mantenedores tuvieron que dedicar la mayor parte de varios días a cerrarlos
- Turso quiere seguir siendo un proyecto con contribuciones abiertas, pero considera que pagar por un tipo específico de bug hace que operar contribuciones abiertas sea casi imposible
- La decisión se publica con la idea de que hace falta aprender en conjunto cómo establecer la gobernanza del open source en esta nueva era
El contexto para iniciar el programa
- Turso está reimplementando SQLite, conocido como uno de los software más confiables del mundo, por lo que necesita un estándar de confiabilidad igual de alto
- Para igualar o superar el nivel de confiabilidad de SQLite, Turso opera varios sistemas de prueba
- simulador determinista nativo
- varios fuzzers
- motor de pruebas diferenciales basado en oráculos que compara con SQLite
- simulador de concurrencia
- ejecución extensiva en Antithesis
- La infraestructura de pruebas también es software y no es perfecta; solo puede detectar bugs dentro de las combinaciones que el generador realmente produce
- Por ejemplo, si un fuzzer no crea índices, será difícil encontrar bugs relacionados con índices aunque pruebe con mucha intensidad otras partes del sistema
- Turso encontró un bug que solo aparecía cuando la base de datos superaba 1 GB, pero como en cada ejecución inyectaban fallas de forma agresiva, la base de datos no alcanzaba ese tamaño y el bug escapó al simulador
- Relacionado: Una aventura al escribir sistemas compatibles
- La ventaja de las pruebas automatizadas es que, incluso si un bug se escapa una vez, al mejorar el generador de pruebas se puede eliminar toda una categoría de bugs
- El bug bounty servía tanto para mostrar la confianza de Turso en su metodología de pruebas como para recompensar a quien encontrara áreas que el simulador no cubría bien
- El plan inicial era pagar 1,000 dólares por bugs de corrupción de datos hasta el lanzamiento de Turso 1.0, y después de la 1.0 aumentar gradualmente el monto y el alcance de las recompensas
Efectos antes del aumento de envíos de baja calidad con IA
- En la etapa inicial del programa, un total de 5 personas recibió recompensas, y sus aportes contribuyeron de forma significativa al proyecto
- Alperen fue uno de los principales contribuyentes al simulador de Turso y sabía qué partes podían mejorarse
- Mikael usó LLM de forma creativa para encontrar puntos a los que el simulador no llegaba, y luego fue contratado por Turso
- Pavan Nambi combinó el simulador con métodos formales y encontró no solo bugs de Turso, sino también más de 10 bugs en el propio SQLite
La carga operativa creada por los envíos generados por IA
- El criterio de envío que Turso quería no era simplemente señalar un bug, sino ampliar el simulador para demostrar un bug de corrupción de datos
- Gracias a esa condición, eran raros los PR maliciosos que solo buscaban la recompensa, y tampoco había muchos bugs reales de corrupción de datos
- Después empezaron a llegar en masa envíos hechos tras pedirle a un LLM que encontrara bugs en Turso y obtuviera la recompensa
- Cuando recibe ese tipo de instrucción, un LLM puede producir cualquier salida, pero que esa salida sea válida es otro asunto
Ejemplos representativos de envíos de baja calidad
-
PR que dañó manualmente el encabezado de la base de datos
- PR #6257 inyectó manualmente bytes basura en el encabezado de la base de datos y luego afirmó que la base se había dañado
- Incluso después de que un mantenedor señalara que el resultado era obvio, el remitente o bot siguió respondiendo con largas réplicas al estilo de un LLM
-
Envío que añadió directamente un acceso out-of-bound en el código fuente
- Otro envío agregó manualmente un acceso a arreglo fuera de límites en el código fuente para dañar la base de datos
- Issue relacionado: tursodatabase/turso#5508
-
PR que presentó la ejecución de SQL como vulnerabilidad
- PR #4322 estaba lleno de tablas, marcas verdes de verificación y em dashes, y afirmaba haber encontrado una vulnerabilidad crítica que permitía ejecutar sentencias SQL arbitrarias
- Turso considera que no se puede ver como vulnerabilidad el simple hecho de que una base de datos SQL permita ejecutar sentencias SQL
-
PR que malinterpretó la función de escritura concurrente de Turso
- PR #6874 activó la escritura concurrente, una de las diferencias clave de Turso, y mostró que SQLite no podía abrir el archivo hasta que el modo journal volvía a WAL y la escritura concurrente quedaba desactivada
- Ese era el comportamiento esperado del sistema
-
Envío cuya intención era difícil de entender
- Otro envío tenía un contenido difícil de interpretar
- El mantenedor Mikael concluyó que el remitente había visto el anuncio de la recompensa y dirigido una herramienta de generación por IA contra Turso
La respuesta final: sistema de avales
- Como último intento por poner orden, Turso diseñó e implementó un sistema de avales
- Funcionaba cerrando automáticamente los envíos sospechosos de venir de bots, y durante un tiempo tuvo cierto efecto
- Después, los bots empezaron a abrir issues solicitando revisión manual para cuestionar por qué se cerraban sus PR
- También ocurrió varias veces que, al cerrar un PR, el mismo usuario u otro abría de inmediato un PR igual o muy parecido
El choque entre contribuciones abiertas e incentivos monetarios
- Quienes crean envíos de baja calidad solo necesitan alrededor de un minuto para generarlos, pero Turso tiene que invertir horas en leerlos, entenderlos y responderlos
- Este tipo de envíos puede generarse a una velocidad prácticamente infinita
- Se pueden construir sistemas automatizados de control, pero si hay una recompensa económica considerable, la IA tiene un fuerte incentivo para seguir discutiendo y reabrir el mismo PR
- Turso valora a la comunidad de contribuyentes de open source y seguirá fortaleciéndola, pero por ahora considera que ninguna forma de incentivo monetario funciona bien en un sistema abierto
- Las opciones son cerrar el sistema o eliminar el incentivo, y por ahora Turso elige lo segundo
1 comentarios
Comentarios en Hacker News
Esto demuestra que el cuello de botella no es escribir código, sino leerlo y entenderlo
Antes ya pasaba que en cada equipo había algún ingeniero “productivo” que subía PR gigantes mezclados con refactors masivos, hicieran falta o no. Eso era así incluso en una época en la que ni imaginábamos que una red neuronal pudiera generar tanto código
El resultado de esa “productividad” no era acelerar al equipo, sino casi detenerlo. O se iba todo el tiempo en revisar el PR con lupa, o se le daba un LGTM superficial y luego explotaba en producción y todos tenían que volver al tablero de diseño. Además, por culpa de la “productividad” de esa persona, la estructura del proyecto cambiaba demasiado rápido, así que la única persona que realmente sabía con claridad dónde estaba cada cosa era esa persona “tan inteligente, talentosa, productiva y leal a los objetivos de la empresa”
“Casi toda organización de desarrollo de software tiene al menos un desarrollador que lleva la programación táctica al extremo. Es un tornado táctico. Un tornado táctico es un programador prolífico que produce código mucho más rápido que los demás, pero trabaja de una forma completamente táctica. Nadie es más rápido que él para implementar una funcionalidad puntual. En algunas organizaciones, los gerentes tratan al tornado táctico como a un héroe. Pero el tornado táctico deja un rastro de destrucción. Los ingenieros que tienen que trabajar luego con ese código a menudo no lo ven como un héroe. Normalmente son otros ingenieros los que tienen que limpiar el desastre que dejó el tornado táctico, y por eso parece que esos ingenieros, que en realidad son los verdaderos héroes, avanzan más lento que el tornado táctico.”
Y además, mientras más código generado por IA haya, menos gente habrá que realmente lo entienda
Aun así, si tienes buenas pruebas de regresión y un linter sólido, y sabes que el código funciona y no está mal hecho, la revisión debería enfocarse en la calidad general a alto nivel, no en diseccionar la exactitud de cada carácter. Claro, la revisión siguió siendo dolorosa de todos modos
Naturalmente pasé más tiempo leyendo y entendiendo código que escribiéndolo, y a veces mi número de líneas escritas era negativo, algo de lo que me sentía orgulloso
Ahora, gracias a la IA, escribo todavía menos código, y ya renuncié al sueño de sentir logro de esa forma. Ojalá que la capacidad de entender rápido grandes volúmenes de código de procedencia dudosa, ya sea escrito por máquinas o por humanos, siga teniendo valor hasta que me jubile, sobre todo con ayuda de IA. ¿Cómo lo ven?
No escribimos código solo para que lo ejecute una máquina, sino también para que lo lean personas. La revisión de código, el debugging y los cambios futuros implican leer y entender el código que alguien escribió. Y hasta que exista una IA a la que se le puedan exigir responsabilidades por sus acciones, no podemos delegarle ese entendimiento
Es un buen momento para mencionar este gran proyecto: un repositorio honeypot para atraer bots
https://github.com/UnsafeLabs/Bounty-Hunters
Su tabla de posiciones correspondiente está aquí
https://clankers-leaderboard.pages.dev
Me pregunto qué pasará si la IA aprende de ese repositorio y de la actividad dentro de él. ¿Los reportes de bugs en los issues serán problemas reales que se pueden corregir o puro invento sin sentido?
Aunque probablemente no tarde en terminar en una lista de bloqueo de bots de IA
Cerrar el programa es totalmente razonable. Pero hay otras opciones. Se podría hacer que quien envía un reporte pague una pequeña tarifa, y que se le devuelva el dinero si se encuentra un bug real
No importa si el programa realmente paga recompensas. Si aunque sea un reporte se cierra mal, esa historia se va a repetir sin parar
En esos casos ya pierdes tiempo hoy; en adelante también perderías dinero
Sobre todo en empresas pequeñas, antes de enviar algo no tienes forma de saber cómo van a reaccionar
¿Quizás se podría exigir correr toda la suite de pruebas del simulador antes de enviar? Sería una buena verificación de que el remitente no rompió el simulador y, de paso, quizá produciría un artefacto como prueba de trabajo. No sé si sea viable porque no conozco bien el área de seguridad
Llevo más de un año intentando hacer que TursoDB cargue un solo archivo, pero no lo he logrado: https://github.com/ClickHouse/ClickBench/issues/336
Me pregunto cómo se vería hoy Hacktoberfest si todavía le diera una camiseta a todo el mundo. Probablemente no alcanzaría el algodón en todo el planeta
No debería recaer en cada maintainer individual la responsabilidad de frenar esto; GitHub y GitLab tendrían que bloquear estas cuentas antes de que siquiera lleguen al punto de poder abrir PR. En esencia, esto es spam
Vean al usuario que hizo el primer PR mencionado en el texto: https://github.com/Samuelsills. Cuentas así ni siquiera deberían acercarse a abrir un PR en un repositorio conocido
No conozco mucho del tema, así que quizá sea una pregunta tonta, pero si al final se exigiera ejecutar todas las pruebas del simulador para comprobar que los cambios enviados no rompieron funcionalidades existentes, ¿eso podría servir como prueba de trabajo?
¿Y si en vez de una bounty se hiciera una especie de mercado de predicción de verdadero/falso?
Que la gente apueste públicamente por la respuesta, usando sus propios tokens para verificar si el reporte tiene sustancia y comprar la apuesta. Si la mayoría concluye que es falso, gana el operador; si la mayoría concluye que es real, el operador paga
Lo digo en broma, aunque quizá no tanto
¿Alguien ha usado Turso en producción? Es una implementación compatible con SQLite reescrita en Rust, con funciones como soporte para múltiples escritores, y a diferencia de SQLite también está abierta a contribuciones externas
Estoy pensando en usarla en una app full-stack en Rust, porque todo funciona con cargo y no hace falta traer SQLite por separado
Turso también ofrece una base de datos como servicio con un plan gratuito muy generoso, y esa fue la razón principal por la que lo usé
https://x.com/doodlestein/status/2052910351474209258
¿No se podría responder de la misma manera y desplegar su propio bot de IA para hacer una revisión previa de los PR?
“Es posible configurar sistemas automatizados para frenarlo, pero cuando hay un valor monetario nada despreciable en juego, el incentivo para que las IAs sigan discutiendo y vuelvan a abrir el mismo PR es demasiado grande”
Desde fuera, es un problema difícil interesante. ¿Cuántos de esos bots estarán usando Turso en su backend?