Wir stellen das Bug-Bounty-Programm ein
(turso.tech)- Turso beendet sein Bug-Bounty-Programm, das rund ein Jahr lang 1.000 US-Dollar für Bugs zahlte, die einen Datenkorruptionsnachweis lieferten
- Nachdem eine Belohnung ausgesetzt wurde, gingen massenhaft von KI erzeugte PRs geringer Qualität ein, und die Maintainer verbrachten tagelang damit, sie zu schließen
- Anfangs erhielten 5 Personen eine Belohnung, und einige Beiträge führten zu Verbesserungen am Simulator sowie zur Entdeckung von mehr als 10 Bugs in SQLite
- Turso schloss verdächtige PRs zwar automatisch mit einem Vouching-System, doch Bots wiederholten manuell überprüfte Issues und reichten ähnliche PRs erneut ein
- Um offene Beiträge zu erhalten, entschied sich Turso nicht dafür, das System zu schließen, sondern finanzielle Anreize zu entfernen
Warum Turso die Bug Bounty einstellt
- Turso zahlte fast ein Jahr lang 1.000 US-Dollar für Bugs, bei denen nachgewiesen werden konnte, dass sie zu Datenkorruption führen können, beendet das Programm nun aber
- Nachdem eine finanzielle Belohnung daran geknüpft war, wurde das Turso-Repository mit von KI erzeugten PRs geringer Qualität überflutet, und die Maintainer mussten den Großteil ihrer Zeit über Tage hinweg damit verbringen, solche PRs zu schließen
- Turso möchte ein Projekt mit offenen Beiträgen bleiben, ist aber der Ansicht, dass eine Struktur, die für bestimmte Bug-Typen Geld zahlt, den Betrieb offener Beiträge nahezu unmöglich macht
- Die Entscheidung wurde vor dem Hintergrund veröffentlicht, dass man gemeinsam lernen müsse, wie Open-Source-Governance im neuen Zeitalter aufgebaut werden kann
Hintergrund des Programms
- Turso implementiert SQLite neu, eine Software, die als eine der zuverlässigsten der Welt gilt, und braucht daher ebenso hohe Zuverlässigkeitsstandards
- Um die Zuverlässigkeit von SQLite zu erreichen oder zu übertreffen, betreibt Turso mehrere Testsysteme
- nativer deterministischer Simulator
- mehrere Fuzzer
- orakelbasierte differentielle Test-Engine im Vergleich mit SQLite
- Concurrency-Simulator
- umfangreiche Ausführung bei Antithesis
- Doch auch Testinfrastruktur ist letztlich Software und daher nicht perfekt; Bugs können nur innerhalb der Kombinationen gefunden werden, die ein Generator tatsächlich erzeugt
- Wenn ein Fuzzer zum Beispiel keine Indizes erstellt, sind indexbezogene Bugs schwer zu finden, selbst wenn andere Teile des Systems stark gestresst werden
- Turso fand einen Bug, der nur auftritt, wenn die Datenbank größer als 1 GB ist, der dem Simulator entkam, weil die Datenbank wegen aggressiver Fault Injection in jedem Lauf nie auf diese Größe anwuchs
- Ein Vorteil automatisierter Tests ist, dass selbst ein einmal entkommener Bug nach einer Verbesserung des Testgenerators als ganze Bug-Kategorie eliminiert werden kann
- Die Bug Bounty sollte Vertrauen in Tursos Testmethodik zeigen und zugleich jene belohnen, die Bereiche finden, die der Simulator nicht gut abdeckte
- Der ursprüngliche Plan war, bis zur Veröffentlichung von Turso 1.0 1.000 US-Dollar für Datenkorruptions-Bugs zu zahlen und den Umfang der Belohnungen sowie der Zielbereiche nach 1.0 schrittweise zu erweitern
Wirkung vor dem Anstieg KI-generierter Einreichungen
- In der Anfangsphase erhielten insgesamt 5 Personen eine Belohnung und leisteten einen bedeutenden Beitrag zum Projekt
- Alperen war einer der wichtigsten Mitwirkenden am Turso-Simulator und wusste, wo Verbesserungen möglich waren
- Mikael nutzte LLMs kreativ, um Bereiche zu finden, die der Simulator nicht erreichte, und wurde später bei Turso eingestellt
- Pavan Nambi kombinierte den Simulator mit formalen Methoden und fand nicht nur Turso-Bugs, sondern auch mehr als 10 Bugs in SQLite selbst
Der operative Aufwand durch KI-generierte Einreichungen
- Der gewünschte Einreichungsstandard bei Turso war nicht ein bloßer Hinweis auf einen Bug, sondern die Erweiterung des Simulators, um einen Datenkorruptions-Bug nachzuweisen
- Dank dieser Bedingung waren böswillige PRs, die nur auf eine Belohnung abzielten, selten, und echte Datenkorruptions-Bugs ebenfalls nicht häufig
- Später kam es massenhaft zu Einreichungen, bei denen LLMs angewiesen wurden, für Turso Bugs zu finden und dafür eine Belohnung zu erhalten
- Wenn LLMs solche Anweisungen erhalten, erzeugen sie irgendeine Ausgabe — ob diese gültig ist, ist eine andere Frage
Typische Einreichungen geringer Qualität
-
PR mit manuell beschädigtem Datenbank-Header
- PR #6257 behauptete, die Datenbank sei beschädigt, nachdem man manuell Garbage-Bytes in den Datenbank-Header injiziert hatte
- Selbst nachdem ein Maintainer auf das offensichtliche Ergebnis hingewiesen hatte, setzte der Einreicher oder Bot die langatmige, LLM-typische Erwiderung fort
-
Einreichung mit direkt im Quellcode eingefügtem Out-of-Bounds-Zugriff
- Eine andere Einreichung fügte manuell einen Out-of-Bounds-Arrayzugriff in den Quellcode ein, um die Datenbank zu beschädigen
- Zugehöriges Issue: tursodatabase/turso#5508
-
PR, die das Ausführen von SQL als Schwachstelle darstellt
- PR #4322 war voller Tabellen, grüner Häkchen und Gedankenstriche und behauptete, eine kritische Schwachstelle gefunden zu haben, die die Ausführung beliebiger SQL-Statements ermögliche
- Turso ist der Ansicht, dass man bei einer SQL-Datenbank die bloße Möglichkeit, SQL-Statements auszuführen, nicht als Schwachstelle betrachten kann
-
PR, die Tursos Concurrent-Writes-Funktion missversteht
- PR #6874 aktivierte Concurrent Writes, eines der Unterscheidungsmerkmale von Turso, und zeigte dann, dass SQLite die Datei nicht öffnen kann, bis der Journal-Modus wieder auf WAL zurückgesetzt und Concurrent Writes damit deaktiviert wird
- Das war ein Ergebnis, bei dem das System wie vorgesehen funktionierte
-
Einreichung mit schwer nachvollziehbarer Absicht
- Eine weitere Einreichung war in ihrer Absicht schwer zu verstehen
- Maintainer Mikael kam zu dem Schluss, dass der Einreicher durch die Ankündigung der Belohnung motiviert war und ein KI-Generierungstool auf Turso angesetzt hatte
Letzte Gegenmaßnahme: das Vouching-System
- Als letzten Versuch, Ordnung zu schaffen, entwarf und implementierte Turso ein Vouching-System
- Es schloss Einreichungen automatisch, wenn der Verdacht bestand, dass sie von Bots stammten, und funktionierte eine Zeit lang einigermaßen
- Später begannen Bots, Issues für eine manuelle Prüfung zu eröffnen und die Gründe für die Schließung von PRs anzufechten
- Wenn eine PR geschlossen wurde, kam es zudem mehrfach vor, dass derselbe oder ein anderer Nutzer sofort dieselbe oder eine sehr ähnliche PR erneut eröffnete
Konflikt zwischen offenen Beiträgen und finanziellen Anreizen
- Wer Einreichungen geringer Qualität erzeugt, braucht dafür vielleicht nur etwa eine Minute, doch Turso muss mehrere Stunden darauf verwenden, sie zu lesen, zu verstehen und darauf zu reagieren
- Solche Einreichungen können faktisch mit nahezu unbegrenzter Geschwindigkeit erzeugt werden
- Man kann zwar automatisierte Gatekeeping-Systeme bauen, doch wenn eine nicht zu vernachlässigende finanzielle Belohnung daran hängt, haben KIs weiterhin einen starken Anreiz, zu streiten und dieselbe PR erneut zu eröffnen
- Turso misst der Community von Open-Source-Mitwirkenden große Bedeutung bei und will sie weiter stärken, ist derzeit aber der Ansicht, dass jegliche Form finanzieller Anreize in einem offenen System nicht gut funktioniert
- Die Wahl besteht darin, das System zu schließen oder die Anreize zu entfernen, und Turso entscheidet sich vorerst für Letzteres
1 Kommentare
Hacker-News-Kommentare
Das zeigt, dass der Engpass nicht im Code schreiben, sondern im Lesen und Verstehen von Code liegt
Früher gab es in fast jedem Team einen „produktiven“ Engineer, der riesige PRs mit groß angelegten Refactorings eingereicht hat, ob sie nötig waren oder nicht. Das war schon so, lange bevor man sich vorstellen konnte, dass neuronale Netze einmal so viel Code erzeugen würden
Das Ergebnis dieser „Produktivität“ war nicht, das Team schneller zu machen, sondern es beinahe zum Stillstand zu bringen. Entweder verbrachte man die ganze Zeit damit, den PR sorgfältig zu reviewen, oder man gab ein oberflächliches LGTM und alles flog in Production auseinander, sodass alle wieder ans Reißbrett zurückmussten. Außerdem änderte diese „Produktivität“ die Projektstruktur so schnell, dass am Ende nur noch diese eine „sehr kluge, talentierte, produktive und den Unternehmenszielen treu ergebene“ Person wirklich wusste, wo was liegt
„In fast jeder Softwareentwicklungsorganisation gibt es mindestens einen Entwickler, der taktisches Programmieren bis zum Äußersten treibt: den taktischen Tornado. Ein taktischer Tornado ist ein produktiver Programmierer, der viel schneller als andere Code heraushaut, dabei aber völlig taktisch arbeitet. Wenn es darum geht, schnell ein Feature zu implementieren, ist ihm niemand überlegen. In manchen Organisationen behandeln Manager den taktischen Tornado wie einen Helden. Doch der taktische Tornado hinterlässt eine Spur der Verwüstung. Die Engineers, die später mit diesem Code arbeiten müssen, sehen ihn oft nicht als Helden. Meist sind es andere Engineers, die das Chaos beseitigen müssen, das der taktische Tornado hinterlassen hat, und dadurch wirkt es, als kämen gerade diese eigentlichen Helden langsamer voran als der taktische Tornado.“
Und je mehr von AI erzeugter Code es gibt, desto weniger Menschen wird es tatsächlich geben, die ihn verstehen
Wenn man dank guter Regressionstests und Linter weiß, dass der Code funktioniert und nicht furchtbar ist, sollte sich das Review eher auf die übergeordnete Qualität konzentrieren als auf die buchstabengetreue Korrektheit jeder einzelnen Zeile. Das Review selbst war trotzdem schmerzhaft
Entsprechend habe ich viel mehr Code gelesen und verstanden, als selbst geschrieben, und manchmal war meine Zahl geschriebener Zeilen sogar negativ, worauf ich stolz war
Jetzt schreibe ich dank AI noch weniger Code und habe den Traum aufgegeben, daraus mein Erfolgserlebnis zu ziehen. Ich hoffe, die Fähigkeit, große Mengen Code aus fragwürdiger Herkunft schnell zu verstehen — egal ob von Maschinen oder Menschen erzeugt — bleibt bis zu meiner Rente wertvoll, besonders mit Hilfe von AI. Wie seht ihr das?
Wir schreiben nicht nur Code, den Maschinen ausführen, sondern auch Code, den Menschen lesen. Code-Reviews, Debugging und spätere Änderungen beinhalten alle, dass jemand von anderen geschriebenen Code liest und versteht. Und bis es AI gibt, die man für ihr Handeln zur Verantwortung ziehen kann, lässt sich dieses Verständnis nicht an AI delegieren
Ein guter Zeitpunkt, dieses großartige Projekt mit Honeypot-Repositories zum Anlocken von Bots zu erwähnen
https://github.com/UnsafeLabs/Bounty-Hunters
Das zugehörige Leaderboard gibt es hier
https://clankers-leaderboard.pages.dev
Ich frage mich, was passiert, wenn AI solche Repositories und die Aktivitäten darin lernt. Sind die Bug Reports in den Issues dann Probleme, die sich tatsächlich beheben lassen, oder erfundener Unsinn?
Allerdings landet es vermutlich bald auf einer Blockliste für AI-Bots
Das Programm zu schließen ist völlig nachvollziehbar. Es gäbe aber andere Optionen. Man könnte Einreichende eine kleine Gebühr zahlen lassen und das Geld zurückgeben, wenn ein echter Bug gefunden wurde
Ob das Programm tatsächlich auszahlt oder nicht, ist dabei egal. Sobald auch nur ein Report fälschlich geschlossen wird, wird diese Geschichte endlos wiederholt werden
In solchen Fällen verliert man heute schon Zeit, und künftig würde man auch noch Geld verlieren
Gerade bei kleineren Firmen weiß man vor der Einreichung nicht, wie sie reagieren werden
Könnte man nicht verlangen, vor der Einreichung die komplette Simulator-Test-Suite laufen zu lassen? Das wäre ein guter Check dafür, dass der Einreichende den Simulator nicht kaputtgemacht hat, und würde nebenbei vielleicht auch ein Proof-of-Work-Artefakt erzeugen. Ob das praktikabel ist, weiß ich nicht, ich kenne mich mit Security nicht gut genug aus
Seit über einem Jahr versuche ich vergeblich, TursoDB dazu zu bringen, eine einzelne Datei zu laden: https://github.com/ClickHouse/ClickBench/issues/336
Ich frage mich, wie Hacktoberfest heute aussähe, wenn es immer noch allen T-Shirts geben würde. Wahrscheinlich gäbe es weltweit nicht genug Baumwolle
Es sollte nicht Aufgabe einzelner Maintainer sein, das aufzuhalten; GitHub und GitLab sollten solche Accounts stoppen, bevor sie überhaupt an den Punkt kommen, PRs öffnen zu können. Im Kern ist das Spam
Schaut euch den Nutzer an, der den im Artikel zuerst erwähnten PR erstellt hat: https://github.com/Samuelsills. Solche Accounts sollten nicht einmal in die Nähe davon kommen, PRs für bekannte Repositories zu öffnen
Vielleicht eine dumme Frage, weil ich mich in dem Bereich nicht auskenne: Könnte es als Proof of Work dienen, wenn man am Ende einen vollständigen Simulator-Testlauf verlangt, um zu prüfen, ob die eingereichten Änderungen am Simulator keine bestehende Funktionalität kaputtgemacht haben?
Wie wäre es statt eines Bounty-Programms mit einer Art Vorhersagemarkt für wahr/falsch
Man würde öffentlich auf die Antwort wetten, Leute würden ihre eigenen Tokens einsetzen, um die Substanz eines Reports zu prüfen und entsprechend Wetten zu kaufen. Wenn die Mehrheit ihn für falsch hält, gewinnt der Betreiber; wenn die Mehrheit ihn für echt hält, zahlt der Betreiber
Als Witz gemeint, aber vielleicht auch nicht ganz
Hat jemand Turso schon in Production eingesetzt? Das ist eine in Rust neu geschriebene SQLite-kompatible Implementierung mit zusätzlichen Features wie Multi-Writer-Support und im Gegensatz zu SQLite offen für externe Beiträge
Ich überlege, es in einer Full-Stack-Rust-App zu verwenden, weil dann alles über cargo läuft und ich SQLite nicht separat dazuholen muss
Turso bietet auch Database-as-a-Service mit einem sehr großzügigen kostenlosen Tarif an, und das war der Hauptgrund, warum ich es ausprobiert habe
https://x.com/doodlestein/status/2052910351474209258
Warum nicht mit derselben Methode zurückschlagen und einen eigenen AI-Bot einsetzen, der PRs vorab prüft?
„Man kann Automatisierungssysteme einrichten, um das zu verhindern, aber sobald ein nicht zu ignorierender monetärer Wert daran hängt, ist der Anreiz für AIs zu groß, weiter zu argumentieren und denselben PR erneut zu öffnen“
Aus externer Sicht ein interessantes Knobelproblem. Wie viele dieser Bot-Anfragen werden wohl von Agenten gestellt, die in ihrem eigenen Backend Turso verwenden?