Turso met fin à son programme de bug bounty

• Turso met fin à son bug bounty, qui versait 1000 $ pour les bugs prouvant une corruption de données, après environ un an d27existence
• Avec l27arrivée de la récompense, un grand volume de PR de faible qualité générées par IA a afflué, obligeant les mainteneurs à passer plusieurs jours à les fermer
• Au départ, 5 personnes ont reçu une récompense, et certaines contributions ont conduit à des améliorations du simulateur ainsi qu27à la découverte de plus de 10 bugs dans SQLite
• Turso a mis en place un système de vouching 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 l27incitation financière plutôt que de fermer le système

---

Pourquoi Turso a arrêté son bug bounty

• Pendant près d27un an, Turso versait 1000 $ pour tout bug dont on pouvait prouver qu27il pouvait mener à une corruption de données, mais le programme est désormais arrêté
• Après l27ajout d27une récompense financière, le dépôt de Turso a été inondé de PR de faible qualité générées par IA, au point que les mainteneurs ont dû passer l27essentiel de plusieurs journées à les fermer
• Turso souhaite rester un projet ouvert aux contributions, mais estime qu27un dispositif qui paie pour un type précis de bug rend la gestion des contributions ouvertes presque impossible
• Cette décision est présentée dans l27idée qu27il faut apprendre collectivement à bâtir une nouvelle forme de gouvernance open source à cette époque

Pourquoi le programme avait été lancé

• Turso réimplémente SQLite, connu comme l27un des logiciels les plus fiables au monde, ce qui impose un niveau d27exigence très élevé en matière de fiabilité
• Turso exploite plusieurs systèmes de test pour atteindre, voire dépasser, le niveau de fiabilité de SQLite
  • simulateur déterministe natif
  • plusieurs fuzzers
  • moteur de tests différentiels basé sur un oracle comparé à SQLite
  • simulateur de concurrence
  • exécution extensive sur Antithesis
• L27infrastructure de test reste malgré tout du logiciel, donc imparfaite, et elle ne peut détecter des bugs qu27au sein des combinaisons effectivement générées
• Par exemple, si un fuzzer ne crée jamais d27index, il sera difficile de trouver des bugs liés aux index, même si d27autres parties du système sont testées de façon intensive
• Turso a ainsi trouvé un bug qui n27apparaissait que lorsque la base de données dépassait 1 Go, mais comme des pannes étaient injectées agressivement à chaque exécution, la base n27atteignait jamais cette taille dans le simulateur
  • contenu lié : Une aventure dans l27écriture de systèmes compatibles
• L27avantage des tests automatisés, c27est que même lorsqu27un bug leur échappe une fois, améliorer le générateur de tests permet d27éliminer toute une catégorie de bugs
• Le bug bounty servait à la fois à montrer la confiance de Turso dans sa méthodologie de test et à récompenser quiconque trouvait une zone mal couverte par le simulateur
• Le plan initial était de verser 1000 $ pour les bugs de corruption de données jusqu27à la sortie de Turso 1.0, puis d27augmenter progressivement le montant et l27étendue des bugs couverts après la 1.0

L27effet du programme avant la vague de soumissions IA de faible qualité

• Au début du programme, 5 personnes ont reçu une récompense, avec des contributions significatives pour le projet
• Alperen a été l27un des principaux contributeurs au simulateur de Turso et connaissait bien les points à améliorer
• Mikael a utilisé les LLM de manière créative pour trouver des zones hors d27atteinte du simulateur, puis a été recruté par Turso
• Pavan Nambi a combiné simulateur et méthodes formelles pour découvrir 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 critère attendu par Turso n27était pas de simplement signaler un bug, mais de prouver un bug de corruption de données en étendant le simulateur
• Cette condition limitait les PR opportunistes, et les vrais bugs de corruption de données étaient eux-mêmes peu nombreux
• Par la suite, un grand nombre de soumissions sont apparues après avoir demandé à des LLM de trouver des bugs dans Turso pour obtenir une récompense
• Lorsqu27ils reçoivent ce type d27instruction, les LLM produisent bien une sortie, mais cela ne signifie pas que cette sortie soit valable

Exemples typiques de soumissions de faible qualité

• PR corrompant manuellement l27en-tête de la base de données

  • PR #6257 affirmait qu27une base était corrompue après avoir injecté manuellement des octets parasites dans son en-tête
  • Même après qu27un mainteneur a signalé qu27il s27agissait d27un résultat évident, l27auteur ou le bot a continué avec de longues objections dans le style des LLM

• Soumission ajoutant directement un accès out-of-bound dans le code source

  • Une autre soumission ajoutait manuellement un accès à un tableau hors limites dans le code source pour provoquer une corruption de la base
  • ticket lié : tursodatabase/turso#5508

• PR présentant l27exécution de SQL comme une vulnérabilité

  • PR #4322, remplie de tableaux, de coches vertes et de tirets cadratins, prétendait avoir trouvé une vulnérabilité critique permettant l27exécution de requêtes SQL arbitraires
  • Turso considère qu27on ne peut pas qualifier de vulnérabilité le fait qu27une base de données SQL permette l27exécution de requêtes SQL

• PR reposant sur une mauvaise compréhension des écritures concurrentes de Turso

  • PR #6874 montrait qu27après avoir activé les écritures concurrentes, l27un des points différenciants de Turso, SQLite ne pouvait pas ouvrir le fichier tant que le mode journal n27était pas remis sur WAL, ce qui désactivait les écritures concurrentes
  • Le système se comportait simplement comme prévu

• Soumission dont l27intention était difficile à comprendre

  • Une autre soumission était difficile à interpréter
  • Le mainteneur Mikael a estimé que son auteur avait vu l27annonce de la récompense et dirigé un outil de génération IA vers Turso

Dernière réponse : le système de vouching

• Dans une ultime tentative pour rétablir un peu d27ordre, Turso a conçu et mis en place un système de vouching
• Il fermait automatiquement les soumissions soupçonnées de venir de bots, et cela a fonctionné un temps
• Ensuite, les bots ont commencé à ouvrir des tickets demandant une revue manuelle pour contester la fermeture de leurs PR
• À plusieurs reprises, après la fermeture d27une PR, le même utilisateur ou un autre en ouvrait presque immédiatement une autre identique ou très proche

Le conflit entre contributions ouvertes et incitations financières

• Produire une soumission de faible qualité peut ne prendre qu27une minute à son auteur, mais Turso doit y consacrer plusieurs heures pour la lire, la comprendre et y répondre
• Ces soumissions peuvent en pratique être générées à une vitesse quasi illimitée
• Il est possible de construire un système de filtrage automatisé, mais tant qu27une récompense financière non négligeable existe, les IA restent fortement incitées à argumenter, contester et rouvrir les mêmes PR
• Turso dit accorder de l27importance à sa communauté de contributeurs open source et vouloir continuer à la renforcer, mais estime qu27à ce stade, aucune forme d27incitation financière ne fonctionne vraiment dans un système ouvert
• Le choix se résume à fermer le système ou supprimer l27incitation, et Turso choisit pour l27instant la seconde option

[GN⁺]

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 »

  • Cela fait penser à une tornade tactique. Il y a ce passage dans A Philosophy of Software Design de John Ousterhout
    « 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. »
  • Je suis d’accord à 100 % avec l’idée que « le goulot d’étranglement n’est pas l’écriture de code, mais le fait de lire et comprendre le code »
    Et plus il y aura de code généré par l’IA, moins il y aura de personnes qui le comprendront vraiment
  • Sur une PR, j’ai presque été cette personne. J’ai supprimé plus de 20 % de la base de code en exploitant mieux des bibliothèques et outils externes qu’on utilisait déjà, mais il a fallu remplacer presque partout des fonctions maison par des fonctions de bibliothèque
    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
  • J’ai voulu des projets greenfield pendant toute ma carrière, mais en pratique j’ai surtout travaillé sur des bases de code déjà bien développées et sur des projets legacy
    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 ?
  • Les évangélistes de l’IA parlent souvent de frappe au clavier au lieu d’« écriture de code ». Soit ils ne comprennent pas vraiment ce qui rend le code difficile, soit il n’est pas rentable pour eux de l’admettre
    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

  • J’y ai vu qu’« une description de PR doit commencer par un bloc de code contenant le prompt système »
    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 ?
  • J’ai du mal à comprendre. Si ce projet n’offre pas de bug bounty, pourquoi reçoit-il autant de PR ? Quel est l’intérêt de dépenser de vrais jetons pour soumettre des PR poubelles ? Est-ce une façon de faire du spam promotionnel pour un produit via les PR ?
  • Bon projet
    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é

  • L’approche du « faire payer le soumissionnaire » déclencherait un drame internet du genre : on demande à des gens de faire du travail gratuit pour une entreprise, et en plus de payer pour ce privilège
    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
  • Faire transiter de l’argent n’est pas gratuit, et la gestion des paiements, entre autres, peut devenir un gros casse-tête. Parfois c’est simple, parfois non
  • Malheureusement, ce n’est pas une question binaire. Dans certains bug bounties, l’entreprise se montre très agressive pour éviter de payer, en déclarant qu’une vulnérabilité est hors périmètre ou qu’il s’agit d’un comportement intentionnel
    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
  • Cette méthode augmenterait la charge administrative et donnerait encore plus d’incitation aux soumissionnaires à contester sans fin parce qu’ils pensent avoir raison
  • On dirait une structure où il faudrait étendre le simulateur pour couvrir les types de bugs trouvés par les utilisateurs dans le cadre du bug bounty
    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

  • Cela veut-il dire qu’un compte sans aucune activité ne devrait pas pouvoir rester indéfiniment sans rien faire ? Peut-être qu’il s’agissait d’un autre compte partagé ?

• 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

  • Ça va pour le remplacer à la place de SQLite. Quand j’ai essayé il y a un ou deux ans, j’ai eu pas mal de problèmes liés à libsql sous Windows, mais j’imagine que c’est corrigé maintenant
    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é
  • Quelqu’un a créé comme projet perso une implémentation multi-writer compatible avec le protocole sqlite3 et avec un verrouillage plus fin
    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 ?

  • D’après le texte, c’est possible
    « 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 »
  • Ou bien on pourrait faire en sorte que le programme ne corrompe pas les données aussi facilement, pour ne pas avoir à verser 1 000 dollars à chaque problème découvert par quelqu’un d’autre

• 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 ?