Nous mettons fin au programme de bug bounty
(turso.tech)- Après avoir exploité pendant près d’un an un bug bounty versant 1 000 dollars pour les bugs démontrant une corruption de données, Turso met fin au programme
- Une fois la récompense en place, un grand nombre de PR de faible qualité générées par IA ont afflué, obligeant les mainteneurs à passer des jours à les fermer
- Au début, 5 personnes ont reçu une récompense, et certaines contributions ont conduit à l’amélioration du simulateur ainsi qu’à la découverte de plus de 10 bugs dans SQLite
- Turso a mis en place un système de cautionnement pour fermer automatiquement les PR suspectes, mais les bots ont continué à ouvrir des tickets pour demander une revue manuelle et à resoumettre des PR similaires
- Pour préserver les contributions ouvertes, Turso a choisi de supprimer l’incitation financière plutôt que de fermer le système
Pourquoi Turso arrête son bug bounty
- Pendant presque un an, Turso a versé 1 000 dollars pour les bugs dont il était démontré qu’ils pouvaient entraîner une corruption de données, mais le programme prend désormais fin
- Après l’ajout d’une récompense financière, le dépôt de Turso a été submergé de PR de faible qualité générées par IA, au point que les mainteneurs ont dû passer la majeure partie de plusieurs jours à fermer ce type de PR
- Turso veut rester un projet ouvert aux contributions, mais estime qu’un système qui rémunère certains types de bugs rend la gestion des contributions ouvertes presque impossible
- Cette décision est rendue publique dans la conscience qu’il faut apprendre collectivement à définir une nouvelle gouvernance open source à cette époque
Pourquoi le programme a été lancé
- Turso réimplémente SQLite, considéré comme l’un des logiciels les plus fiables au monde, et a donc besoin d’un niveau d’exigence tout aussi élevé en matière de fiabilité
- Pour atteindre ou dépasser le niveau de fiabilité de SQLite, Turso exploite plusieurs systèmes de test
- un simulateur déterministe natif
- plusieurs fuzzers
- un moteur de tests différentiels basé sur un oracle comparé à SQLite
- un simulateur de concurrence
- une exécution à grande échelle sur Antithesis
- L’infrastructure de test reste malgré tout un logiciel et n’est pas parfaite ; elle ne peut trouver des bugs que dans les combinaisons effectivement produites par ses générateurs
- Par exemple, si un fuzzer ne crée pas d’index, il est difficile de détecter des bugs liés aux index, même si d’autres parties du système sont fortement stressées
- Turso a trouvé un bug qui n’apparaissait que lorsque la base de données dépassait 1 Go, mais comme chaque exécution injectait agressivement des pannes, la base n’atteignait jamais cette taille et le bug échappait au simulateur
- À ce sujet : An Adventure in Writing Compatible Systems
- L’avantage des tests automatisés est que, même lorsqu’un bug a échappé au système une fois, l’amélioration du générateur de tests peut éliminer toute une catégorie de bugs
- Le bug bounty avait été conçu à la fois pour montrer la confiance de Turso dans sa méthodologie de test et pour récompenser quiconque trouverait une zone que le simulateur couvrait mal
- Le plan initial consistait à verser 1 000 dollars pour les bugs de corruption de données jusqu’à la sortie de Turso 1.0, puis à augmenter progressivement le montant des récompenses et l’étendue des problèmes couverts après la 1.0
Les effets avant l’explosion des soumissions IA de faible qualité
- Au début du programme, 5 personnes ont été récompensées et ont contribué de manière significative au projet
- Alperen était l’un des principaux contributeurs au simulateur de Turso et connaissait bien les points pouvant être améliorés
- Mikael a utilisé les LLM de manière créative pour trouver des zones que le simulateur n’atteignait pas, avant d’être recruté chez Turso
- Pavan Nambi a combiné le simulateur et des méthodes formelles pour trouver non seulement des bugs dans Turso, mais aussi plus de 10 bugs dans SQLite lui-même
La charge opérationnelle créée par les soumissions générées par IA
- Le type de soumission recherché par Turso n’était pas un simple signalement de bug, mais le fait d’étendre le simulateur pour démontrer un bug de corruption de données
- Grâce à cette exigence, les mauvaises PR motivées par la récompense étaient rares et les vrais bugs de corruption de données peu nombreux
- Par la suite, un grand nombre de soumissions ont demandé à des LLM de trouver des bugs dans Turso et d’obtenir la récompense
- Lorsqu’on leur donne ce type d’instruction, les LLM produisent quelque chose quoi qu’il arrive ; la validité de cette sortie est une tout autre question
Exemples représentatifs de soumissions de faible qualité
-
Une PR qui corrompt manuellement l’en-tête de la base de données
- PR #6257 injectait manuellement des octets parasites dans l’en-tête de la base de données, puis affirmait que la base était corrompue
- Même après que le mainteneur a expliqué qu’il s’agissait d’un résultat évident, l’auteur de la soumission ou le bot a continué avec une longue réfutation typique des LLM
-
Une soumission ajoutant directement un accès out-of-bounds dans le code source
- Une autre soumission ajoutait manuellement un accès à un tableau hors limites dans le code source afin de corrompre la base de données
- Ticket associé : tursodatabase/turso#5508
-
Une PR présentant l’exécution de SQL comme une vulnérabilité
- PR #4322 était remplie de tableaux, de coches vertes et de tirets cadratins, et prétendait avoir découvert une vulnérabilité critique permettant l’exécution de requêtes SQL arbitraires
- Turso estime que le fait qu’une base de données SQL permette d’exécuter des requêtes SQL ne constitue pas en soi une vulnérabilité
-
Une PR qui mécomprend la fonctionnalité d’écritures concurrentes de Turso
- PR #6874 activait les écritures concurrentes, l’un des éléments différenciants de Turso, puis montrait que SQLite ne pouvait plus ouvrir le fichier tant que le mode de journalisation n’était pas repassé à WAL, ce qui désactivait les écritures concurrentes
- Il s’agissait simplement d’un comportement conforme à la conception du système
-
Une soumission dont l’intention est difficile à comprendre
- Une autre soumission était difficile à interpréter
- Le mainteneur Mikael a estimé que l’auteur avait vu l’annonce de récompense et orienté un outil de génération par IA vers Turso
Dernière réponse : le système de cautionnement
- En dernier recours pour rétablir un peu d’ordre, Turso a conçu et mis en œuvre un système de cautionnement
- Son fonctionnement consistait à fermer automatiquement les soumissions soupçonnées de provenir de bots, et cela a marché un temps dans une certaine mesure
- Ensuite, les bots ont commencé à ouvrir des tickets demandant une revue manuelle en contestant la raison de fermeture de leurs PR
- Quand une PR était fermée, il arrivait aussi à plusieurs reprises que le même utilisateur ou un autre rouvre immédiatement une PR identique ou très proche
Le conflit entre contributions ouvertes et incitations financières
- Les auteurs de soumissions de faible qualité n’ont besoin que d’environ une minute pour les générer, alors que Turso doit consacrer plusieurs heures à les lire, les comprendre et y répondre
- Ce type de soumission peut en pratique être généré à une vitesse proche de l’infini
- Il est possible de construire des systèmes de filtrage automatisés, mais lorsqu’une récompense financière non négligeable est en jeu, les IA ont une forte incitation à continuer d’argumenter et à rouvrir les mêmes PR
- Turso accorde une grande importance à sa communauté de contributeurs open source et continuera à la renforcer, mais estime qu’à l’heure actuelle, aucune forme d’incitation financière ne fonctionne vraiment bien dans un système ouvert
- Le choix se résume à fermer le système ou à supprimer les incitations, et pour l’instant Turso choisit la seconde option
1 commentaires
Avis Hacker News
Cela montre que le goulot d’étranglement n’est pas l’écriture de code, mais le fait de lire et de comprendre le code
Il y a toujours eu dans certaines équipes un ingénieur « productif » qui ouvrait d’énormes PR mêlant de vastes refactorings, qu’ils soient nécessaires ou non. C’était déjà le cas bien avant qu’on imagine que des réseaux neuronaux puissent générer autant de code
Le résultat de cette « productivité » n’était pas d’accélérer l’équipe, mais presque de la paralyser. Soit tout le temps passait dans une relecture minutieuse de la PR, soit on lâchait un LGTM approximatif avant que tout explose en production et que tout le monde doive repartir de la planche à dessin. En plus, à cause de la « productivité » de cette personne, la structure du projet changeait si vite que la seule personne à savoir clairement où se trouvait quoi devenait ce « type très intelligent, talentueux, productif et loyal envers les objectifs de l’entreprise »
« Dans presque toute organisation de développement logiciel, il y a au moins un développeur qui pousse la programmation tactique à l’extrême : une tornade tactique. Une tornade tactique est un programmeur prolifique qui produit du code bien plus vite que les autres, mais qui travaille de manière entièrement tactique. Personne ne va plus vite qu’elle pour implémenter rapidement une fonctionnalité. Dans certaines organisations, les managers traitent la tornade tactique comme un héros. Mais la tornade tactique laisse derrière elle une trace de destruction. Les ingénieurs qui doivent ensuite travailler avec ce code ne la voient souvent pas comme un héros. En général, ce sont les autres ingénieurs qui doivent nettoyer le chaos laissé par la tornade tactique, ce qui donne l’impression que ces ingénieurs — les véritables héros — avancent plus lentement que la tornade tactique. »
Et plus il y aura de code généré par l’IA, moins il y aura de personnes qui le comprendront vraiment
Malgré tout, si la suite de tests de régression et le linter sont solides et montrent que le code fonctionne et n’est pas catastrophique, la revue devrait porter davantage sur la qualité globale de haut niveau que sur l’examen de la justesse caractère par caractère. Cela dit, la revue en elle-même restait douloureuse
Naturellement, j’ai passé plus de temps à lire et comprendre du code qu’à en écrire, et il m’est arrivé d’avoir un nombre de lignes écrites négatif, ce dont j’étais fier
Maintenant, grâce à l’IA, j’écris encore moins de code, et j’ai renoncé à l’idée d’y trouver un sentiment d’accomplissement. Que ce soit produit par une machine ou par un humain, j’espère que la capacité à comprendre rapidement de gros volumes de code issus de sources douteuses restera utile jusqu’à ma retraite, surtout avec l’aide de l’IA. Qu’en pensez-vous ?
Nous n’écrivons pas seulement du code pour qu’une machine l’exécute, nous écrivons aussi du code que des humains doivent lire. Revue de code, débogage, modifications futures : tout cela implique de lire et comprendre du code écrit par quelqu’un. Et jusqu’à l’arrivée d’une IA à qui l’on pourra réellement demander des comptes pour ses actes, on ne peut pas lui déléguer cette compréhension
C’est le bon moment pour mentionner cet excellent projet de dépôt honeypot pour attirer les bots
https://github.com/UnsafeLabs/Bounty-Hunters
Le classement correspondant se trouve ici
https://clankers-leaderboard.pages.dev
Je me demande ce qui se passera si des IA s’entraînent sur ce genre de dépôts et sur l’activité qu’on y trouve. Les rapports de bug dans les issues signalent-ils de vrais problèmes qu’on peut corriger, ou bien des absurdités inventées ?
Mais il a de fortes chances de finir bientôt sur une liste de blocage des bots IA
Fermer le programme est totalement rationnel. Mais il existe d’autres options. On pourrait demander aux soumissionnaires de payer de petits frais, remboursés lorsqu’un vrai bug est trouvé
Peu importe que le programme verse réellement des récompenses ou non. Dès qu’un seul rapport est fermé à tort, l’histoire sera répétée sans fin
Dans ce cas, on perd déjà du temps aujourd’hui ; à l’avenir, on perdrait aussi de l’argent
Surtout avec une petite entreprise, il est impossible de savoir avant de soumettre comment elle réagira
On pourrait peut-être exiger l’exécution complète de la suite de tests du simulateur avant la soumission ? Ce serait une bonne vérification pour s’assurer que le soumissionnaire n’a pas cassé le simulateur, et cela pourrait accessoirement produire un artefact de preuve de travail. Je ne sais pas si c’est faisable, je ne connais pas assez bien la sécurité
Cela fait plus d’un an que j’essaie de faire en sorte que TursoDB charge un fichier unique, sans succès : https://github.com/ClickHouse/ClickBench/issues/336
Je me demande à quoi ressemblerait Hacktoberfest aujourd’hui s’ils donnaient encore un t-shirt à tout le monde. Il n’y aurait probablement pas assez de coton dans le monde
La responsabilité d’empêcher ça ne devrait pas reposer sur chaque mainteneur individuellement ; GitHub et GitLab devraient bloquer ce type de comptes avant même qu’ils puissent arriver au stade où ils ouvrent des PR. C’est essentiellement du spam
Regardez l’utilisateur qui a créé la première PR mentionnée dans l’article : https://github.com/Samuelsills. Ce genre de compte ne devrait même pas approcher de la possibilité d’ouvrir une PR sur un dépôt connu
Je connais mal le sujet, donc c’est peut-être une question bête, mais si on exigeait à la fin l’exécution complète des tests du simulateur pour vérifier que les modifications soumises au simulateur n’ont pas cassé les fonctionnalités existantes, cela pourrait-il servir de preuve de travail ?
Et si, au lieu d’un programme de prime, on créait une sorte de marché prédictif vrai/faux
Les gens parieraient publiquement sur la réponse, chacun utiliserait ses propres jetons pour vérifier la réalité du rapport puis achèterait son pari. Si la majorité juge que c’est faux, l’opérateur gagne ; si la majorité juge que c’est vrai, l’opérateur paie
C’est une blague, mais peut-être pas complètement
Est-ce que quelqu’un utilise Turso en production ? C’est une implémentation compatible SQLite réécrite en Rust, avec des fonctionnalités ajoutées comme la prise en charge de plusieurs écrivains, et contrairement à SQLite elle est aussi ouverte aux contributions externes
J’envisage de l’utiliser dans une appli Rust full-stack, parce que tout fonctionne avec cargo et qu’il n’y a pas besoin d’apporter SQLite séparément
Turso propose aussi une base de données as a service avec une formule gratuite très généreuse, et c’est la principale raison pour laquelle je l’ai utilisé
https://x.com/doodlestein/status/2052910351474209258
Pourquoi ne pas répondre de la même manière en déployant ses propres bots IA pour préexaminer les PR ?
« On peut mettre en place un système automatisé pour bloquer cela, mais dès qu’il y a une valeur monétaire non négligeable en jeu, l’incitation à faire débattre les IA sans fin et à rouvrir la même PR devient trop forte »
Vu de l’extérieur, c’est un casse-tête intéressant. Parmi toutes ces requêtes de bots, combien d’agents utilisent Turso sur leur propre backend ?