बग बाउंटी प्रोग्राम बंद किया जा रहा है

• Turso ने लगभग 1 साल तक उस बग बाउंटी प्रोग्राम को चलाने के बाद बंद कर दिया, जिसमें डेटा करप्शन साबित करने वाले बग पर $1,000 दिए जाते थे
• इनाम घोषित होने के बाद AI से बने कम-गुणवत्ता वाले PR बड़ी संख्या में आने लगे, और maintainers को इन्हें बंद करने में कई दिन लगाने पड़े
• शुरुआत में 5 लोगों को इनाम मिला, और कुछ योगदानों से simulator में सुधार हुआ तथा SQLite में 10 से अधिक बग मिले
• Turso ने संदिग्ध PR को अपने आप बंद करने के लिए vouching system लगाया, लेकिन bots ने manual review issues और मिलते-जुलते PR दोबारा भेजने शुरू कर दिए
• Turso ने open contributions बनाए रखने के लिए सिस्टम बंद करने के बजाय monetary incentive हटाने का विकल्प चुना

---

Turso ने बग बाउंटी क्यों रोकी

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

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

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

AI कम-गुणवत्ता submissions बढ़ने से पहले का असर

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

AI-जनित submissions से बना operational बोझ

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

कम-गुणवत्ता submissions के प्रतिनिधि उदाहरण

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

  • PR #6257 में database header में हाथ से garbage bytes inject किए गए और फिर दावा किया गया कि database corrupt हो गया
  • maintainer ने इसे स्वाभाविक नतीजा बताया, फिर भी submitter या bot ने LLM-शैली की लंबी दलीलें जारी रखीं

• source code में सीधे out-of-bound access जोड़ने वाली submission

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

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

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

• Turso की concurrent writes सुविधा को गलत समझने वाला PR

  • PR #6874 ने Turso की खास क्षमताओं में से एक concurrent writes को enable किया, फिर journal mode को WAL पर वापस बदलकर concurrent writes बंद करने से पहले दिखाया कि SQLite file नहीं खोल सकता
  • यह सिस्टम के डिजाइन के मुताबिक ही होने वाला व्यवहार था

• ऐसा submission जिसका उद्देश्य समझना मुश्किल था

  • एक और submission में यह समझना मुश्किल था कि वह करना क्या चाहता है
  • maintainer Mikael का मानना था कि submitter ने इनाम की घोषणा देखकर AI-generated tool को Turso पर लक्षित किया था

आख़िरी उपाय: vouching system

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

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

• कम-गुणवत्ता submissions बनाने वाले पक्ष को ऐसी submission तैयार करने में लगभग 1 मिनट लगता है, लेकिन Turso को उन्हें पढ़ने, समझने और जवाब देने में कई घंटे लगाने पड़ते हैं
• ऐसी submissions व्यावहारिक रूप से लगभग अनंत गति से बनाई जा सकती हैं
• 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 इस्तेमाल कर रहे होंगे?