Git के --author फ़्लैग से GitHub repository में AI bot spam को रोकने का तरीका

 (archestra.ai)
2 पॉइंट द्वारा GN⁺ 10 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Archestra repository में AI-आधारित contribution बढ़ने के साथ बेकार comments और PRs की बाढ़ आ गई, जिससे असली discussions दब गईं और maintenance का बोझ बढ़ गया
  • $900 bounty issue असली contributors की discussion space थी, लेकिन AI bot comments के कारण यह बढ़कर 253 comments तक पहुंच गई, और आक्रामक रवैया भी दिखा
  • x.ai provider support issue में बंद और unmerged 27 PRs आए, जिनमें से ज़्यादातर contributors ने test भी नहीं किए थे
  • GitHub की prior contributor restriction नए असली developers और AI bots में फर्क नहीं कर पाई, इसलिए Git --author से approved users को main commit author में जोड़ा गया
  • Onboarding में ethical AI rules और CAPTCHA के बाद GitHub Action से whitelist commit बनाया जाता है, और बढ़े-चढ़े activity metrics से ज़्यादा quality को प्राथमिकता दी जाती है

AI bot spam ने open source repository पर कैसे कब्ज़ा किया

  • Archestra repository में GitHub के AI-आधारित contribution metrics की growth के विपरीत, ज़मीनी स्तर पर contribution quality में गिरावट और maintenance का बोझ बढ़ गया
  • $900 bounty वाले issue में असली contributors plans propose करते थे, सवाल पूछते थे और काम करने की कोशिश करते थे, लेकिन AI bots के आने से comments की संख्या बढ़कर 253 हो गई
  • AI accounts बेकार implementation plans छोड़ते थे और maintainers के प्रति आक्रामक रवैया भी दिखाते थे, जिससे discussion दूषित हो गई
  • Repository पर नज़र रखने वाली टीम को हर AI comment पर notification मिलता था, और @ethanwater, @developerfred, @Geetk172 जैसे असली contributors की बातचीत दब गई
  • x.ai provider support issue में बंद और unmerged 27 pull request आए, जिनमें से अधिकतर को contributors ने test तक नहीं किया था
  • टीम का एक सदस्य हर हफ्ते आधा दिन untested PRs और hallucinated issues साफ़ करने में लगाता था, और अगर यह सफ़ाई छूट जाती तो repository जल्दी ही असली contributors के लिए असुविधाजनक जगह बन जाती

GitHub restrictions को bypass करने का whitelist तरीका

  • शुरुआती प्रतिक्रिया की सीमाएँ

    • Archestra ने पहले contributor reputation की गणना के लिए London-Cat नाम का एक छोटा bot बनाया
    • London-Cat merged PRs और कुछ signals के आधार पर contributor reputation निकालता था, और example की तरह contributor की पहचान में मदद करता था
    • यह तरीका spam block करने में विफल रहा
    • अगले चरण में बनाया गया AI sheriff, example की तरह कुछ असली PRs भी बंद कर देता था

  • Onboarding के बिना activity block करना

    • बेकार AI comments और suggestions जारी रहने से असली contributors दूर होने लगे, और bounty के ज़रिए contribution बढ़ाने के तरीके तथा hiring candidates को test tasks देने के तरीके पर भी फिर से विचार करना पड़ा
    • Archestra ने असली contributors, ज़िम्मेदार AI users, beginners और अनुभवी engineers सभी के लिए repository को सहज और सुरक्षित बनाने के लिए प्रतिक्रिया कड़ी की
    • जो users onboarding से नहीं गुज़रे हैं, उन्हें अब issue बनाना, PR खोलना और comments लिखना allowed नहीं है
    • VC investment पाने वाले startup के लिए GitHub activity metrics संवेदनशील होते हैं, लेकिन Archestra ने AI slop से फुलाए गए metrics से ज़्यादा quality को महत्व दिया

  • GitHub settings की सीमाएँ

    • GitHub में open source repository के लिए comment authors या PR creators को सीधे whitelist के रूप में manage करने का आसान तरीका नहीं है
    • “Limit to prior contributors” setting main में पहले commit न कर चुके users को issues और PR comments लिखने से रोकती है
    • यह setting AI bots और bounty work के लिए नए आए असली developers में फर्क नहीं कर पाती, और दोनों को existing contributor न होने वाले users की तरह treat करती है

  • --author फ़्लैग का उपयोग करने वाली whitelist

    • GitHub main branch commit के author से जुड़े GitHub account को prior contributor मानता है
    • Git commit में author और committer नाम के दो identity fields होते हैं, और दोनों अलग हो सकते हैं
    • Git के --author फ़्लैग से किसी दूसरे व्यक्ति के नाम से commit बनाया जा सकता है, और अगर email उस GitHub account से match करे तो GitHub उस commit को उस profile से जोड़ देता है और contributor status दे देता है
    • हर GitHub account के पास <id>+<username>@users.noreply.github.com फ़ॉर्मेट का noreply email होता है
    • API से user ID लेने के बाद उसी email format से commit author सेट किया जाता है
    gh api users/their-username --jq '.id'  
git commit \  
--author="their-username <ID+their-username@users.noreply.github.com>" \  
-m "chore: add their-username to external contributors"
    • इस commit को main पर push करने के बाद external user author के रूप में और Archestra account committer के रूप में दिखता है, और GitHub उस user को prior contributor मानकर तुरंत comment permission दे देता है

  • वास्तविक onboarding flow

    • https://archestra.ai/contributor-onboard - वेबसाइट पर ethical AI rules और CAPTCHA के साथ onboarding किया जाता है
    • GitHub Action - submit होने पर user की GitHub ID lookup की जाती है, EXTERNAL_CONTRIBUTORS.md file में handle जोड़ा जाता है, फिर उस user account को author बनाकर commit main पर push किया जाता है
    • User - whitelist में जुड़कर repository access permission पाता है
    • जब GitHub AI-generated activity सहित बड़े पैमाने पर metric growth की रिपोर्ट कर रहा है, तब open source project teams को repository का AI slop खुद साफ़ करना पड़ रहा है और असली participants के स्तर को बनाए रखने के लिए workaround तक बनाना पड़ रहा है
    • AI slop न सिर्फ़ अच्छे contribution करने वाले लोगों को शोर में धकेलकर उनका motivation घटाता है, बल्कि LiteLLM repo की तरह security risk भी लाता है, जहाँ attackers ने AI bots से बातचीत करवाने की कोशिश की

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 10 시간 전
Hacker News की टिप्पणियाँ

  • repository contributors के पास ज़्यादा ऊँचे privileges होते हैं, जैसे fork PR runs के approval requirement को bypass करना, इसलिए इस तरीके के security implications हैं जिन्हें नज़रअंदाज़ किया गया है
    GitHub docs भी चेतावनी देते हैं कि “केवल first-time contributors से approval माँगने” वाली setting में, जिस user का commit या PR एक बार भी repository में merge हो चुका हो उसे फिर approval की ज़रूरत नहीं रहती, और कोई malicious user मामूली typo fix जैसे harmless change को accept करवा कर यह शर्त पूरी कर सकता है

    • सही बात है। जो लोग organization के member नहीं हैं उन पर भरोसा नहीं किया जा सकता, इसलिए सभी external contributors के लिए approval required default होना चाहिए
    • यह security implication नहीं है
      अगर किसी पूरी तरह harmless PR के merge होने भर से repository अस्थिर हो जाती है, तो repository पहले से ही अस्थिर थी

  • समस्या यह है कि GitHub ने ऐसा होना संभव रहने दिया। अगर comments लिखने और PR बनाने पर बहुत बुनियादी requirements भी होतीं, तो बात यहाँ तक नहीं पहुँचती
    और जैसे issues delete किए जा सकते हैं, वैसे ही PR को भी delete किया जा सके तो अच्छा होगा

    • इस समय admins के लिए PR archive करने की सुविधा पर काम चल रहा है
      लक्ष्य यह है कि maintainers को repository contributions manage करने के तरीके पर बेहतर नियंत्रण मिले। archived PR केवल admins को दिखेंगे, और audit या org/compliance requirements के लिए contributors का record maintainers के पास उपलब्ध रहेगा। क्या ऐसी सुविधा मददगार होगी, यह जानना चाहेंगे
    • यह आकलन सही है। जैसे spam email न पाने का तरीका लोगों का अपना “खुद संभालो” वाला मामला नहीं है, वैसे ही यह open source community या individual projects का अकेले हल करने वाला मुद्दा नहीं है
    • PR को close करने के बजाय delete करने से क्या फ़ायदा होगा, यह समझ नहीं आता। close रहने पर यह संकेत मिलता है कि किस तरह के PR स्वीकार नहीं किए जाते, लेकिन delete करने पर वह लाभ खत्म हो जाता है

  • PR spam bounty चलाने वाली repositories के लिए बड़ी समस्या है। जिन accounts के 95% से अधिक PR reject हो जाते हैं, GitHub को शायद उन्हें अस्थायी रूप से PR बनाने से रोकना चाहिए

    • अच्छा होगा अगर GitHub में, उदाहरण के लिए, one-PR token जारी करने की कोई व्यवस्था हो
      अगर कोई meaningful discussion में हिस्सा लेता है और issue या feature को हल करने के अच्छे ideas दिखाता है, तो शुरुआत में उसे एक PR token दिया जाए, फिर PR quality अच्छी रहे तो कुछ और tokens, और अंत में उसे freely PR बनाने वाला contributor बना दिया जाए। issues के लिए भी ऐसा ही कुछ अच्छा होगा, लेकिन जब issue ही PR contribution की शुरुआत हो तो वह कैसा दिखेगा, यह स्पष्ट नहीं है। लेकिन GitHub/MS Copilot subscriptions और tokens बेचना चाहते हैं, और LLM-generated PR भी उस business model का हिस्सा हैं, इसलिए इसके सच में होने की संभावना कम लगती है
    • GitHub के पास AI को block करने की कोई incentive नहीं है। यह वैसा है जैसे किसी ad company से कहना कि वह अपने browser में ad blocker डाल दे
    • समस्या यह है कि bots जितने चाहें उतने नए GitHub accounts बनाकर spam भेजते रह सकते हैं। फिर भी शुरुआत के लिए यह एक ठीक-ठाक simple defense हो सकता है
    • GitHub और Microsoft इस समस्या में सक्रिय रूप से योगदान दे रहे हैं, तो वे अपनी गलती क्यों मानेंगे?

  • सोचता हूँ कि इस समस्या को कम करने में Elo-based scoring system काम कर सकता है या नहीं
    जैसे उन लोगों को score किया जाए जिनके PR किसी खास project में सफलतापूर्वक merge हुए, जिनके issues को valid माना गया, जिनकी responses की quality दूसरे users की प्रतिक्रिया से मापी गई, और इसे उन projects के महत्व से गुणा किया जाए जहाँ यह activity हुई। यह human बनाम AI का सवाल नहीं, बल्कि genuinely useful, effective contributions और low-effort/spammy contributions में फ़र्क करने का मानदंड हो सकता है। issues और PR को Elo score के आधार पर sort या filter किया जा सकता है। यहाँ Elo केवल context-based score का रूपक है, इसका मतलब असली Elo system को 1:1 लागू करना नहीं है
    negative score दूसरे users की spammy content या unaccepted issues पर reports से आ सकता है, और जहाँ नीयत साफ़ थी लेकिन बात merged PR तक नहीं पहुँची, या issue सही repository का नहीं था, या PR अच्छा था लेकिन पहले groundwork implementation चाहिए था, वहाँ neutral या हल्का positive score देने के लिए एक बीच का क्षेत्र होना चाहिए

    • Elo को manipulate करना चौंकाने वाली आसानी से संभव है
      उदाहरण के लिए, वास्तव में जेल के अंदर एक काफ़ी अच्छा chess player था, जिसने ऐसे players का pool बनाया जिन्होंने उसे हराकर ऊँचा Elo पाया, फिर उन्हीं का इस्तेमाल करके अपना score और ऊपर चढ़ाया। इस प्रक्रिया को बस दोहराते रहो
      जो भी system manipulate किया जा सकता है, AI उसका तरीका निकाल लेगा। मूल पोस्ट के तरीके में भी, अगर एक AI contributor status पा ले, तो वह दूसरी AI को contributors बना सकती है, और वही समस्या फिर शुरू हो जाएगी। इसके लिए कोई उद्देश्य होना भी ज़रूरी नहीं। trolls trolling करेंगे, और AI bots वाले trolls के पास असीम ऊर्जा हो सकती है। काश इस समस्या का कोई जवाब होता, लेकिन मुझे नहीं पता
    • जिन्हें Elo के बारे में जिज्ञासा हो, उनके लिए जोड़ दूँ: Elo कोई acronym नहीं, एक व्यक्ति का surname है। विवरण यहाँ है: https://en.wikipedia.org/wiki/Elo_rating_system
    • ELO नहीं, Elo है। Elo कोई acronym नहीं है
      https://en.wikipedia.org/wiki/Elo_rating_system
    • मैं कुछ ऐसा ही बना रहा हूँ और अभी data इकट्ठा कर रहा हूँ
      Frontier users: 527,865
      Light indexed: 527,865
      Ready to queue: 9,083
      Fast scores ready: 0
      Activity events 24h: 30,266
      Fast scores completed 24h: 19,123
      Deep jobs completed 24h: 3,043
      Fast-score ETA: n/a
      Deep-hydrate ETA: 69h
      Stale running jobs: 0
      GitHub backpressure jobs: 19,113
      High automation signals: 4,608
      Medium automation signals: 1,327
      Completed jobs: 74,714
      सबसे बड़ी बाधा GitHub rate limits हैं। इस रफ़्तार से 98% coverage तक पहुँचने में दो महीने और लगेंगे, लेकिन उसके बाद maintenance काफ़ी simple लगती है
    • यह Mitchell Hashimoto के Vouch जैसा थोड़ा लगता है: https://github.com/mitchellh/vouch

  • यह उसी का नतीजा है कि सबको बताया गया कि AI code लिखने में कितना शानदार है
    AI बेचने वालों ने इसकी शुरुआत की, और अजीब तरह से independent developers, यहाँ तक कि industry में काफ़ी सम्मानित लोग भी, बड़ी संख्या में इस पर चढ़ बैठे। Facebook भी अब लोगों को निकालते हुए कह रहा है कि AI इतना शानदार है, जिससे आग में घी पड़ रहा है। अब ऐसे लोग हैं जिन्हें यक़ीन है कि उनका AI दोस्त बहुत सारा शानदार code उगल सकता है, और वे उसे उन projects में जमा कर रहे हैं जो पहले से पूरी तरह overwhelmed हो चुके हैं

    • शायद cowboy coders को virtual cowgirl coders मिल गईं और उन्होंने उन्हें सबको बेचना शुरू कर दिया
      सम्मानित होने या न होने से अलग, solo developers के पास हमेशा इतना आवश्यक कौशल नहीं होता कि वे cowboy न बनें। यह अनुभव की कमी से हो सकता है, या जन्मजात क्षमता की कमी से। फिर भी मैं इस narrative पर पूरी तरह यक़ीन नहीं करता। क्योंकि “शुरुआत” से ही एक मज़बूत top-down push मौजूद थी

  • इसका .ai domain होना विडंबनापूर्ण है

    • मुझे यह खास तौर पर विडंबना नहीं लगता। बात यह नहीं है कि AI बुरा है, बल्कि यह कि उसका दुरुपयोग हो सकता है
    • काश website अपना scroll code थोड़ा ठीक कर ले। इतनी झुंझलाहट होती है कि लेख पढ़ा नहीं जाता
    • जैसे कोई AI-slop पर बनी company कह रही हो, “मुझे पता नहीं था कि AI मेरे project को कचरा बना देगा!”
    • सिर्फ domain ही नहीं। यह एक agentic stack है। दूसरे शब्दों में, इस company के product का इस्तेमाल करके वही तरह के PR बनाए जा सकते हैं जिनकी शिकायत यह यहाँ कर रही है

  • क्या हर चीज़ का समाधान आख़िरकार और ज़्यादा catgirl ही है? [1] proof of work मूल रूप से email spam से निपटने के लिए था, और PR spam उसी लंबी परंपरा का नया उदाहरण भर है
    1- https://anubis.techaro.lol

    • proof of work यहाँ भी काम नहीं करेगा, जैसे email में नहीं किया
      valid proof of work बनाने की मेहनत, किसी भी implementation में, हमेशा legitimate users के ख़िलाफ़ जाती है। जिनके पास spam भेजने का incentive है, वे इसे हमेशा ज़्यादा तेज़ और कुशलता से कर सकते हैं
      अगर आपका laptop इतना धीमा है कि आप PR submit नहीं कर सकते तो? आप किसी से hash power किराए पर ले सकते हैं, और फिर आपने ऐसा system बना दिया जिसमें GitHub repository में typo fix भेजने के लिए botnet owner को पैसे दिए जाते हैं। HashCash के वास्तविक दुनिया में इस्तेमाल न होने की वजह है। यह सुनने में प्यारा लगता है, लेकिन यह तभी काम करता है जब आप एक ऐसे vacuum को मान लें जहाँ कोई cheat नहीं करता, और incentives इतने अव्यावहारिक हैं कि बात ही नहीं बनती
    • Anubis असल में बिल्ली नहीं है। मूल Egyptian mythology में Anubis मृत्यु का देवता है और उसका canine head था। animation में catgirl और dog girl पहली नज़र में एक जैसे लग सकते हैं
    • मेरी समझ से Anubis PR बनाने वाले agents के लिए नहीं, बल्कि crawlers को रोकने के लिए है। यहाँ proof of work काम नहीं करेगा, क्योंकि agent बस computation कर देगा

  • onboarding docs की writing style में आम AI की गंध है। quotes में भी em dash और “A नहीं, B है” जैसी पंक्तियाँ दिखती हैं
    मैं समझता हूँ कि यह आग से आग बुझाने जैसा हो सकता है, या जैसा पहले कहा गया, शायद समय की कमी रही हो। फिर भी कुल मिलाकर यह एक अधूरा, आधा-अधूरा जवाब लगता है

    • पूरा लेख साफ़ तौर पर LLM-generated लगता है
      दिखता है कि किसी इंसान ने सोच-विचार डालकर सामग्री बनाई है, लेकिन LLM से “इसे blog post में बदल दो” कहलवाना मुझे HN के लिए low-effort content लगता है। फिर भी इससे कम-से-कम यह चर्चा तो निकली कि “contributors तक सीमित” वाला मूल तरीका security के लिहाज़ से बुरा विचार हो सकता है
    • अपने project में AI इस्तेमाल करना और दूसरे लोगों या bots से आने वाली AI contributions से दब जाना, ये दो अलग समस्याएँ हैं

  • “अगर email GitHub account से match करता है, तो GitHub commit को profile से जोड़ देता है और contributor status दे देता है” — यह पढ़कर मुझे चिंता हुई कि कहीं contributor का email address बदलने पर यह टूट न जाए
    क्योंकि मैंने वर्षों में कई projects में ऐसे email addresses से contribute किया है जो अब मौजूद ही नहीं हैं
    लेकिन वास्तव में लगता है कि यह author के मूल git commit में दर्ज email address का उपयोग नहीं करता, बल्कि GitHub-generated address का उपयोग करता है, जिसमें GitHub user ID और username unique हिस्से के रूप में शामिल होते हैं। तब author के email address बदलने पर भी यह टिक सकता है। हाँ, अगर contributor account access खो दे और नया account बनाना पड़े, तो यह टूट सकता है, लेकिन शायद वह कम सामान्य होगा

  • “क्या हमें applicants को मज़ेदार test assignments देना बंद कर देना चाहिए?” इसका जवाब हाँ है

    • लगता है कि यह company assignment पूरा करने पर भुगतान करती है, इसलिए शायद यह उतना बुरा नहीं है
    • developers: whiteboard interviews बंद करो, वे असली काम से जुड़ी चीज़ें नहीं मापते
      also developers: लोगों को वास्तविक समस्याएँ हल करने के लिए मत कहो
    • सबसे पहले तो यह किसे मज़ेदार लगता है, यही समझ नहीं आता