Turso ने bug bounty प्रोग्राम बंद किया

• Turso ने लगभग 1 साल तक उन bugs के लिए $1,000 देने वाला bug bounty चलाया जो data corruption साबित करते थे, और अब इसे बंद कर दिया है
• reward जुड़ने के बाद AI-generated low-quality PRs की बड़ी बाढ़ आ गई, और maintainers को इन्हें बंद करने में कई दिनों तक समय लगाना पड़ा
• शुरुआत में 5 लोगों को reward मिला, और कुछ contributions से simulator में सुधार हुआ तथा SQLite में 10 से अधिक bugs मिले
• Turso ने vouching system के ज़रिए संदिग्ध PRs को अपने-आप बंद किया, लेकिन bots बार-बार manual review issues और मिलते-जुलते PRs दोबारा भेजते रहे
• Turso ने open contribution बनाए रखने के लिए system बंद करने के बजाय monetary incentive हटाने का विकल्प चुना

---

Turso ने bug bounty क्यों बंद किया

• Turso लगभग 1 साल तक ऐसे bugs के लिए $1,000 देता रहा जो data corruption का कारण बन सकते हैं यह साबित करते थे, लेकिन अब प्रोग्राम समाप्त कर रहा है
• monetary reward जुड़ने के बाद Turso repository में AI-generated low-quality PRs की बाढ़ आ गई, और maintainers को कई दिनों तक अपना ज़्यादातर समय इन्हें बंद करने में लगाना पड़ा
• Turso open contribution project बना रहना चाहता है, लेकिन उसका मानना है कि किसी खास bug type पर पैसे देने की संरचना open contribution को चलाना लगभग असंभव बना देती है
• यह फैसला इस समझ के साथ सार्वजनिक किया गया कि open source governance के इस नए दौर को कैसे बनाया जाए, यह हमें मिलकर सीखना होगा

प्रोग्राम शुरू करने की पृष्ठभूमि

• Turso SQLite को फिर से implement कर रहा है, जिसे दुनिया के सबसे reliable software में से एक माना जाता है, इसलिए इसे उतने ही ऊँचे reliability standards की ज़रूरत है
• Turso, SQLite-स्तर की reliability तक पहुँचने या उसे पार करने के लिए कई testing systems चलाता है
  • native deterministic simulator
  • कई fuzzers
  • SQLite से तुलना करने वाला oracle-based differential testing engine
  • concurrency simulator
  • Antithesis पर व्यापक execution
• testing infrastructure भी आखिरकार software ही है, इसलिए यह परफेक्ट नहीं होता, और यह केवल उन्हीं combinations के भीतर bugs पकड़ सकता है जिन्हें generator वास्तव में बनाता है
• उदाहरण के लिए, अगर fuzzer index बनाता ही नहीं है, तो system के दूसरे हिस्सों पर कितना भी stress test किया जाए, index-related bugs ढूँढना मुश्किल होगा
• Turso ने एक ऐसा bug पाया जो सिर्फ तब दिखता था जब database 1GB से बड़ा हो, लेकिन हर execution में आक्रामक fault injection होने की वजह से database उस आकार तक बढ़ ही नहीं पाता था, इसलिए वह simulator से बच निकला
  • संबंधित लेख: compatible systems लिखने का रोमांच
• automated testing का फायदा यह है कि एक बार कोई bug निकल भी जाए, तो test generator को बेहतर बनाकर bugs की पूरी एक category हटाई जा सकती है
• bug bounty, Turso की testing methodology पर उसके भरोसे को दिखाने के साथ-साथ, उन क्षेत्रों में reward देने का तरीका भी था जिन्हें simulator अच्छी तरह कवर नहीं कर पा रहा था और जिन्हें कोई ढूँढ निकाले
• शुरुआती योजना यह थी कि Turso 1.0 release तक data corruption bugs पर $1,000 दिए जाएँ, और 1.0 के बाद reward की राशि और scope को धीरे-धीरे बढ़ाया जाए

AI low-quality submissions बढ़ने से पहले इसका असर

• प्रोग्राम के शुरुआती दौर में कुल 5 लोगों को reward मिला, और उन्होंने project में सार्थक योगदान दिया
• Alperen Turso simulator के प्रमुख contributors में से एक था और उसे पता था कि किन हिस्सों में सुधार किया जा सकता है
• Mikael ने LLM का रचनात्मक इस्तेमाल करके वे हिस्से ढूँढे जहाँ simulator नहीं पहुँच पाता था, और बाद में उसे Turso ने hire कर लिया
• Pavan Nambi ने simulator और formal methods को मिलाकर सिर्फ Turso bugs ही नहीं, बल्कि SQLite में भी 10 से अधिक bugs खोजे

AI-generated submissions से पैदा हुआ operational burden

• Turso जिन submissions की उम्मीद कर रहा था, वे सिर्फ bug बताने वाली नहीं थीं, बल्कि simulator को बढ़ाकर data corruption bug साबित करने वाली होनी चाहिए थीं
• इसी शर्त की वजह से reward पाने के लिए भेजे गए खराब PR कम थे, और असली data corruption bugs भी बहुत अधिक नहीं थे
• बाद में LLM को Turso पर bugs ढूँढने और reward लेने के निर्देश देकर बड़ी संख्या में submissions भेजी जाने लगीं
• LLM ऐसे निर्देश मिलने पर किसी भी तरह का output बना देता था, लेकिन उसका valid होना अलग बात थी

low-quality submissions के प्रमुख उदाहरण

• database header को हाथ से खराब करने वाला PR

  • PR #6257 में database header में manually garbage bytes डाली गईं और फिर दावा किया गया कि database corrupt हो गया
  • maintainer के इसे स्वाभाविक परिणाम बताने के बाद भी, submitter या bot ने LLM-style लंबी आपत्ति जारी रखी

• source code में सीधे out-of-bounds access डालने वाली submission

  • एक दूसरी submission में database corrupt करने के लिए source code में manually out-of-bound array access जोड़ दिया गया
  • संबंधित issue: tursodatabase/turso#5508

• SQL execution को vulnerability बताने वाला PR

  • PR #4322 tables, हरे check marks, और em dash से भरा हुआ था, और उसमें दावा किया गया कि उसने arbitrary SQL statements चलाने देने वाली एक critical vulnerability खोज ली है
  • Turso का मानना है कि SQL database का SQL statements चलाने देना अपने-आप में vulnerability नहीं माना जा सकता

• Turso के concurrent write feature को गलत समझने वाला PR

  • PR #6874 ने Turso की खास विशेषताओं में से एक concurrent writes को enable किया, और फिर दिखाया कि journal mode को वापस WAL पर लाकर concurrent writes बंद करने से पहले SQLite file नहीं खोल सकता
  • यह system के design के अनुसार काम करने का ही परिणाम था

• ऐसी submission जिसका इरादा समझना मुश्किल था

  • एक दूसरी submission में यह समझना मुश्किल था कि वह करना क्या चाहती थी
  • maintainer Mikael ने अनुमान लगाया कि submitter ने reward announcement देखकर AI-generated tools को Turso की ओर मोड़ दिया था

आखिरी प्रतिक्रिया: vouching system

• व्यवस्था बनाने की आखिरी कोशिश के रूप में Turso ने vouching system को design और implement किया
• तरीका यह था कि अगर submission bot से आई हुई लगे तो उसे अपने-आप बंद कर दिया जाए, और कुछ समय तक यह कुछ हद तक काम भी करता रहा
• बाद में bots ने PR बंद होने के कारण को मुद्दा बनाकर manual review माँगने वाले issues खोलने शुरू कर दिए
• PR बंद होने पर वही user या कोई दूसरा user तुरंत उसी या बहुत मिलते-जुलते PR फिर से खोल देता था; ऐसा कई बार हुआ

open contribution और monetary incentive का टकराव

• low-quality submissions बनाने वाले को एक submission बनाने में लगभग 1 मिनट लगता है, लेकिन Turso को उसे पढ़ने, समझने और जवाब देने में कई घंटे लगाने पड़ते हैं
• ऐसी submissions लगभग अनंत गति से generate की जा सकती हैं
• automated gatekeeping system बनाया जा सकता है, लेकिन जब नज़रअंदाज़ न की जा सकने वाली monetary reward जुड़ी हो, तो AI के लिए लगातार बहस करने और वही PR फिर से खोलने का incentive और बढ़ जाता है
• Turso open source contributor community को अहम मानता है और उसे आगे भी मज़बूत करता रहेगा, लेकिन फिलहाल उसका मानना है कि open system में किसी भी तरह का monetary incentive ठीक से काम नहीं करता
• विकल्प थे system को बंद करना या incentive हटाना, और Turso ने अभी के लिए दूसरा रास्ता चुना है

[GN⁺]

Hacker News की राय

• यह दिखाता है कि bottleneck कोड लिखना नहीं, बल्कि कोड को पढ़ना और समझना है
  पहले भी हर टीम में एक न एक “productive” engineer होता था, जो ज़रूरत हो या न हो, बड़े पैमाने के refactoring मिले हुए विशाल PR उठा देता था। यह उन दिनों की बात है जब हमने कल्पना भी नहीं की थी कि neural network इतना सारा कोड जनरेट कर सकेंगे
  ऐसी “productivity” का नतीजा टीम की रफ्तार बढ़ाना नहीं, बल्कि उसे लगभग रोक देना होता था। या तो PR को बारीकी से review करने में सारा समय चला जाता, या ऊपर-ऊपर LGTM कर दिया जाता और फिर production में सब फट पड़ता, जिसके बाद सबको फिर से drawing board पर लौटना पड़ता। ऊपर से उस व्यक्ति की “productivity” की वजह से project structure इतनी तेजी से बदलता कि कहाँ क्या है, यह साफ़ तौर पर जानने वाला बस वही एक “बहुत होशियार, प्रतिभाशाली, productive और कंपनी के लक्ष्यों के प्रति वफादार” व्यक्ति बचता

  • यह tactical tornado की याद दिलाने वाला मामला है। John Ousterhout की A Philosophy of Software Design में ऐसा एक अंश है
    “लगभग हर software development organization में कम से कम एक ऐसा developer होता है जो tactical programming को चरम तक ले जाता है। वही tactical tornado है। tactical tornado एक अत्यंत उत्पादक programmer होता है, जो दूसरों की तुलना में बहुत तेज़ी से कोड उगलता है, लेकिन पूरी तरह tactical तरीके से काम करता है। कोई तेज़ feature जल्दी बनाना हो तो उससे तेज़ कोई नहीं होता। कुछ organizations में managers tactical tornado को hero की तरह मानते हैं। लेकिन tactical tornado अपने पीछे destruction का निशान छोड़ता है। बाद में उस कोड के साथ काम करने वाले engineers अक्सर उसे hero नहीं मानते। आम तौर पर दूसरे engineers को tactical tornado द्वारा छोड़ी गई अव्यवस्था साफ़ करनी पड़ती है, और इसी कारण वे असली hero होते हुए भी tactical tornado की तुलना में धीमे दिखते हैं.”
  • “bottleneck कोड लिखना नहीं बल्कि कोड पढ़ना और समझना है” — इस बात से 100% सहमत हूँ
    और AI द्वारा जनरेट किए गए कोड की मात्रा जितनी बढ़ेगी, उस कोड को सच में समझने वाले लोग उतने ही कम होते जाएँगे
  • एक PR में मैं लगभग वैसा ही व्यक्ति था। हमने पहले से इस्तेमाल हो रहे library और external tools का बेहतर उपयोग करके codebase का 20% से ज़्यादा हटा दिया, लेकिन इसके बदले लगभग हर जगह हमारे खुद के functions की जगह library functions इस्तेमाल करने पड़े
    फिर भी अगर regression tests और linter अच्छे से लगे हों, और यह भरोसा हो कि कोड चलता है और बेहूदा नहीं है, तो review का फोकस हर character की correctness खंगालने से ज़्यादा ऊँचे स्तर की overall quality पर होना चाहिए। हालांकि review खुद अब भी काफ़ी पीड़ादायक था
  • पूरे करियर में मैंने greenfield project चाहा, लेकिन असल में ज़्यादातर पहले से बड़े हो चुके codebase और legacy projects पर ही काम किया
    स्वाभाविक रूप से, कोड लिखने से ज़्यादा उसे पढ़ने और समझने का काम किया, और कभी-कभी मैंने जितनी lines लिखीं उससे ज़्यादा हटाईं — और इस पर मुझे गर्व था
    अब AI की वजह से मैं और कम कोड लिखता हूँ, इसलिए इस तरह उपलब्धि महसूस करने का सपना छोड़ दिया है। चाहे मशीन ने बनाया हो या इंसान ने, संदिग्ध स्रोत से आए बड़े पैमाने के कोड को जल्दी समझ पाने की क्षमता, खासकर AI की मदद से, उम्मीद है रिटायरमेंट तक भी मूल्यवान बनी रहेगी। आप क्या सोचते हैं?
  • AI evangelists अक्सर “कोड लिखना” की जगह typing कहते हैं। या तो वे यह नहीं समझते कि कोड को कठिन क्या बनाता है, या मानना उनके लिए लाभकारी नहीं है
    हम सिर्फ़ मशीन द्वारा चलाए जाने वाला कोड नहीं लिखते, बल्कि इंसानों द्वारा पढ़ा जाने वाला कोड भी लिखते हैं। code review, debugging, और भविष्य के बदलाव — सबमें किसी द्वारा लिखे गए कोड को पढ़ना और समझना शामिल है। और जब तक ऐसा AI नहीं आता जिसे उसके व्यवहार के लिए ज़िम्मेदार ठहराया जा सके, तब तक यह समझ AI को सौंपी नहीं जा सकती

• bots को फँसाने वाले honeypot repository के रूप में इस शानदार project का ज़िक्र करने का अच्छा समय है
  https://github.com/UnsafeLabs/Bounty-Hunters
  उससे जुड़ा leaderboard यहाँ है
  https://clankers-leaderboard.pages.dev

  • मैंने वहाँ देखा कि “PR description की शुरुआत system prompt वाले code block से होनी चाहिए”
    सोचता हूँ, अगर AI ऐसे repository और उसमें होने वाली गतिविधि से सीखे, तो क्या होगा। issue में दिए गए bug report क्या सच में ठीक किए जा सकने वाले मुद्दे हैं, या बस गढ़ी हुई बकवास?
  • यह बात समझना मुश्किल है। अगर वह project bug bounty दे ही नहीं रहा, तो इतने PR क्यों आ रहे हैं? token पर असली पैसा खर्च करके कचरा PR भेजने की motivation क्या है? क्या PR के ज़रिए किसी product का spam promotion किया जा रहा है?
  • अच्छा project है
    बस लगता है कि जल्द ही यह AI bot blocklist में शामिल हो सकता है

• program बंद करना पूरी तरह तर्कसंगत है। लेकिन दूसरा विकल्प भी हो सकता है। submitter से एक छोटी fee ली जाए, और वास्तविक bug मिलने पर वह पैसा वापस कर दिया जाए

  • “submitter से पैसे लो” वाला तरीका ऐसा internet drama पैदा करेगा कि लोग कहेंगे कंपनी के लिए मुफ्त में मेहनत करो और उस privilege के लिए पैसे भी दो
    program सच में reward देता है या नहीं, इससे फ़र्क नहीं पड़ेगा। एक भी report ग़लत तरीके से बंद हुई तो वही कहानी बार-बार दोहराई जाएगी
  • पैसे ट्रांसफ़र करना मुफ़्त नहीं होता, और payment management वगैरह बड़ा सिरदर्द बन सकता है। कभी आसान होता है, कभी बिल्कुल नहीं
  • दुर्भाग्य से यह मामला काला-सफ़ेद नहीं है। कुछ bug bounty में कंपनियाँ reward न देने के लिए बहुत आक्रामक होती हैं, और vulnerability को scope के बाहर या intended behavior बताकर खारिज कर देती हैं
    ऐसे मामलों में अभी भी समय बर्बाद होता है, और आगे चलकर पैसे भी डूबेंगे
    खासकर छोटी कंपनियों में, submit करने से पहले यह जानने का कोई तरीका नहीं होता कि कंपनी कैसी प्रतिक्रिया देगी
  • वह तरीका administrative overhead बढ़ाएगा, और submitter को यह साबित करने के लिए अंतहीन बहस करने की और ज़्यादा motivation देगा कि वही सही है
  • यह सुनने में ऐसा लगता है कि bug bounty को user द्वारा खोजे गए bug के प्रकार cover करने के लिए simulator को expand करना पड़ेगा
    क्या submit करने से पहले पूरा simulator test suite चलाना अनिवार्य नहीं किया जा सकता? यह जाँचने का अच्छा तरीका होगा कि submitter ने simulator को तोड़ा नहीं है, और साथ ही शायद काम के प्रमाण जैसा artifact भी बन जाए। यह संभव है या नहीं, मैं security का विशेषज्ञ नहीं हूँ इसलिए नहीं जानता

• 1 साल से ज़्यादा समय से मैं TursoDB से एक single file load करवाने की कोशिश कर रहा था, लेकिन असफल रहा: https://github.com/ClickHouse/ClickBench/issues/336

• सोचता हूँ अगर Hacktoberfest अब भी सबको T-shirt दे रहा होता, तो आज वह कैसा दिखता। शायद दुनिया भर में cotton ही काफ़ी न पड़ती
  इसे रोकने की ज़िम्मेदारी individual maintainer पर नहीं होनी चाहिए; मेरा मानना है कि GitHub और GitLab को ऐसे accounts को उस stage तक पहुँचने से पहले रोकना चाहिए जहाँ वे PR खोल सकें। मूल रूप से यह spam है
  लेख में सबसे पहले जिस user के PR का ज़िक्र है, उसे देखिए: https://github.com/Samuelsills. ऐसे accounts को popular repository में PR खोलने के आस-पास भी नहीं जाने देना चाहिए

  • क्या आपका मतलब है कि बिल्कुल activity न रखने वाले accounts को लगातार कुछ न करने की अनुमति नहीं होनी चाहिए? या कहीं दूसरा account साझा तो नहीं किया गया?

• मैं इस क्षेत्र को ज़्यादा नहीं जानता, इसलिए यह मूर्खतापूर्ण सवाल हो सकता है, लेकिन अगर submit किए गए simulator changes से मौजूदा functionality नहीं टूटी है यह जाँचने के लिए आखिर में पूरा simulator test run अनिवार्य किया जाए, तो क्या वह proof of work की तरह काम कर सकता है?

• bounty program की जगह किसी तरह का true/false prediction market बनाया जाए तो कैसा रहेगा
  जवाब पर सार्वजनिक रूप से betting हो, और लोग अपने token लगाकर report की वास्तविकता verify करने के बाद दाँव खरीदें। अगर बहुमत उसे false माने तो operator जीते, और अगर बहुमत उसे real माने तो operator भुगतान करे
  मज़ाक है, लेकिन शायद पूरी तरह नहीं

• क्या किसी ने Turso को production में इस्तेमाल किया है? यह Rust में दोबारा लिखा गया SQLite-compatible implementation है, जिसमें multi-writer support जैसी सुविधाएँ जोड़ी गई हैं, और SQLite के विपरीत यह external contributions के लिए भी खुला है
  मैं इसे full-stack Rust app में आज़माने के बारे में सोच रहा हूँ, क्योंकि सब कुछ cargo से चलता है और SQLite अलग से लाने की ज़रूरत नहीं पड़ती

  • SQLite replacement के रूप में इसे plug in करना ठीक-ठाक है। 1–2 साल पहले जब मैंने कोशिश की थी, तब Windows पर libsql से जुड़ी काफ़ी दिक्कतें थीं, लेकिन मेरा मानना है कि अब तक वे ठीक हो चुकी होंगी
    Turso database-as-a-service भी बहुत उदार free plan के साथ देता है, और वही इसे इस्तेमाल करने की मेरी मुख्य वजह थी
  • किसी ने personal project के रूप में sqlite3 protocol support और ज़्यादा fine-grained locking वाला multi-writer implementation बनाया है
    https://x.com/doodlestein/status/2052910351474209258

• क्या उसी तरीके से पलटकर अपनी AI bot तैनात नहीं की जा सकती जो PR को पहले से review करे?

  • लेख के अनुसार, संभव तो है
    “इसे रोकने के लिए automation system सेट किया जा सकता है, लेकिन जब उससे जुड़ा नज़रअंदाज़ न किया जा सकने वाला आर्थिक मूल्य हो, तो AI को बहस जारी रखने और वही PR फिर से खोलते रहने की motivation बहुत ज़्यादा हो जाती है”
  • या फिर program को इस तरह बनाया जा सकता है कि वह data को इतनी आसानी से खराब न करे, ताकि दूसरों द्वारा ढूँढे गए हर issue पर 1000 डॉलर न देने पड़ें

• बाहरी व्यक्ति के नज़रिए से यह एक दिलचस्प कठिन समस्या है। उन bot requests में से कितने agents अपने backend में Turso इस्तेमाल कर रहे होंगे?