Turso stellt Bug-Bounty-Programm ein
(turso.tech)- Turso hat sein Bug-Bounty-Programm, das rund ein Jahr lang 1.000 US-Dollar für Bugs zahlte, die nachweislich zu Datenkorruption führten, eingestellt
- Mit der Auslobung der Prämie kam es zu einem massiven Zustrom von KI-generierten PRs niedriger Qualität, sodass Maintainer tagelang damit beschäftigt waren, sie zu schließen
- Anfangs erhielten 5 Personen eine Belohnung, und einige Beiträge führten zu Verbesserungen des Simulators sowie zur Entdeckung von mehr als 10 Bugs in SQLite
- Turso setzte ein Vouching-System ein, um verdächtige PRs automatisch zu schließen, doch Bots stellten wiederholt Issues für manuelle Überprüfung ein und reichten ähnliche PRs erneut ein
- Um offene Beiträge beizubehalten, entschied sich Turso nicht dafür, das System zu schließen, sondern finanzielle Anreize zu entfernen
Warum Turso das Bug-Bounty-Programm eingestellt hat
- Turso zahlte fast ein Jahr lang 1.000 US-Dollar für Bugs, die nachweislich zu Datenkorruption führen können, beendet das Programm nun aber
- Nach Einführung der finanziellen Belohnung wurde das Turso-Repository mit KI-generierten PRs niedriger Qualität überflutet, und die Maintainer mussten tagelang den Großteil ihrer Zeit 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 Fehlertypen Geld zahlt, den Betrieb offener Beiträge nahezu unmöglich macht
- Die Entscheidung wurde mit dem Bewusstsein veröffentlicht, dass man gemeinsam lernen müsse, wie Open-Source-Governance in einer neuen Ära aufgebaut werden kann
Hintergrund des Programms
- Turso implementiert SQLite, eine der zuverlässigsten Softwares der Welt, neu und braucht deshalb entsprechend hohe Zuverlässigkeitsstandards
- Turso betreibt mehrere Testsysteme, um das Zuverlässigkeitsniveau von SQLite zu erreichen oder zu übertreffen
- nativer deterministischer Simulator
- mehrere Fuzzer
- orakelbasierte differentielle Test-Engine zum Vergleich mit SQLite
- Simulator für Nebenläufigkeit
- umfangreiche Ausführung auf Antithesis
- Aber auch Testinfrastruktur ist letztlich Software und nicht perfekt; Bugs können nur innerhalb der Kombinationen gefunden werden, die ein Generator tatsächlich erzeugt
- Wenn ein Fuzzer beispielsweise keine Indizes erstellt, ist es selbst bei starkem Stresstesting anderer Teile des Systems schwer, indexbezogene Bugs zu finden
- Turso fand einen Bug, der nur auftrat, wenn die Datenbank größer als 1 GB war; weil bei jedem Lauf aggressiv Fehler injiziert wurden, wuchs die Datenbank nie auf diese Größe an und entging so dem Simulator
- Der Vorteil automatisierter Tests besteht darin, dass man selbst dann, wenn ein Bug einmal entkommt, durch Verbesserung des Testgenerators eine ganze Bug-Kategorie beseitigen kann
- Das Bug-Bounty-Programm sollte sowohl das Vertrauen von Turso in seine Testmethodik zeigen als auch Menschen belohnen, wenn sie Bereiche fanden, 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 nach 1.0 Höhe und Umfang der Belohnungen schrittweise auszuweiten
Wirkung vor dem Anstieg KI-generierter Einreichungen
- In der Anfangsphase erhielten insgesamt 5 Personen eine Belohnung und leisteten damit einen bedeutenden Beitrag zum Projekt
- Alperen war einer der wichtigsten Beitragenden zum 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 von Turso eingestellt
- Pavan Nambi kombinierte den Simulator mit formalen Methoden und fand damit nicht nur Turso-Bugs, sondern auch mehr als 10 Bugs in SQLite selbst
Operative Belastung durch KI-generierte Einreichungen
- Der von Turso gewünschte Standard für Einreichungen war nicht bloß das Melden eines Bugs, sondern den Simulator zu erweitern, um einen Datenkorruptions-Bug nachzuweisen
- Dadurch waren böswillige PRs, die nur auf eine Belohnung abzielten, selten, und echte Datenkorruptions-Bugs gab es ebenfalls nicht viele
- Später gab es massenhaft Einreichungen, bei denen LLMs angewiesen wurden, in Turso Bugs zu finden und eine Belohnung zu kassieren
- LLMs erzeugten auf solche Anweisungen zwar irgendeine Ausgabe, doch ob diese gültig war, stand auf einem anderen Blatt
Typische Beispiele für minderwertige Einreichungen
-
PR mit manuell beschädigtem Datenbank-Header
- PR #6257 behauptete, die Datenbank sei beschädigt, nachdem man manuell Datenmüll in den Datenbank-Header geschrieben hatte
- Selbst nachdem ein Maintainer darauf hingewiesen hatte, dass dies ein offensichtliches Ergebnis sei, setzte der Einreicher oder Bot die langatmige, LLM-typische Gegenrede fort
-
Einreichung mit direkt in den Source Code eingebautem Out-of-Bounds-Zugriff
- Eine andere Einreichung fügte dem Source Code manuell einen Out-of-Bounds-Array-Zugriff hinzu, um die Datenbank zu beschädigen
- Zugehöriges Issue: tursodatabase/turso#5508
-
PR, die SQL-Ausführung als Schwachstelle darstellte
- PR #4322 war voller Tabellen, grüner Häkchen und Em Dashes und behauptete, eine kritische Schwachstelle gefunden zu haben, die die Ausführung beliebiger SQL-Anweisungen erlaube
- Turso sieht es nicht als Schwachstelle an, dass eine SQL-Datenbank überhaupt SQL-Anweisungen ausführen kann
-
PR, die Tursos Funktion für gleichzeitige Schreibvorgänge missverstand
- PR #6874 aktivierte gleichzeitige Schreibvorgänge, eines der Unterscheidungsmerkmale von Turso, und zeigte dann, dass SQLite die Datei nicht öffnen konnte, bis der Journal-Modus wieder auf WAL zurückgestellt und damit gleichzeitiges Schreiben deaktiviert wurde
- Das war ein Ergebnis davon, dass das System wie vorgesehen funktionierte
-
Einreichung mit schwer nachvollziehbarer Absicht
- Eine weitere Einreichung war in ihrer Absicht schwer zu erkennen
- Maintainer Mikael ging davon aus, dass der Einreicher die Ankündigung der Belohnung gesehen und ein KI-Generierungstool auf Turso angesetzt hatte
Letzte Gegenmaßnahme: Vouching-System
- Turso entwickelte und implementierte als letzten Versuch, Ordnung herzustellen, ein Vouching-System
- Wenn eine Einreichung verdächtig nach einem Bot aussah, wurde sie automatisch geschlossen; eine Zeit lang funktionierte das einigermaßen
- Später begannen Bots, Issues mit der Bitte um manuelle Überprüfung zu eröffnen und als Problem anzuführen, warum ihre PR geschlossen worden war
- Nach dem Schließen eines PRs kam es zudem mehrfach vor, dass derselbe oder ein anderer Nutzer sofort denselben oder einen sehr ähnlichen PR erneut eröffnete
Konflikt zwischen offenen Beiträgen und finanziellen Anreizen
- Wer minderwertige Einreichungen erstellt, braucht dafür vielleicht nur etwa eine Minute, doch Turso muss Stunden aufwenden, um sie zu lesen, zu verstehen und darauf zu reagieren
- Solche Einreichungen lassen sich faktisch mit nahezu unbegrenzter Geschwindigkeit erzeugen
- Man kann zwar automatisierte Gatekeeping-Systeme bauen, aber wenn eine nennenswerte Geldprämie daran hängt, haben KIs weiterhin einen starken Anreiz, zu argumentieren und denselben PR erneut zu öffnen
- Turso misst seiner Open-Source-Community große Bedeutung bei und will sie weiter stärken, ist derzeit aber der Ansicht, dass keine Form finanzieller Anreize in einem offenen System gut funktioniert
- Die Wahl bestehe zwischen einem geschlossenen System oder dem Abschaffen der Anreize; Turso habe sich vorerst für Letzteres entschieden
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?