अगर आप बेकार रिपोर्टों से हमारा समय बर्बाद करेंगे, तो हम आपको बैन करेंगे और सार्वजनिक रूप से आपका मज़ाक उड़ाएँगे

• curl open source project के /.well-known/security.txt में दर्ज सामग्री
• यह अपने उत्पाद में पाए गए security issues की reports स्वीकार करता है, लेकिन रिपोर्ट किए गए issues के लिए कोई monetary reward या किसी भी प्रकार का compensation नहीं देता
• इसके बजाय, सत्यापित issues के लिए documentation में acknowledgement और credit देने की बात कही गई है
• अगर कोई घटिया या अर्थहीन reports देकर समय बर्बाद करता है, तो सार्वजनिक रूप से मज़ाक उड़ाने और block करने की चेतावनी दी गई है
• security reporting policy के मुख्य बिंदुओं को संक्षेप में बताने के लिए security.txt standard format का उपयोग किया गया है

---

curl project की security reporting policy

• curl open source project curl project द्वारा बनाए गए products में security issues की reports स्वीकार करता है
  • reports ईमेल ([e-mail]) या GitHub Security Advisory page के माध्यम से भेजी जा सकती हैं
• कोई compensation policy नहीं होने की बात स्पष्ट रूप से कही गई है, और किसी भी monetary या अन्य प्रकार का reward नहीं दिया जाता
  • इसके बजाय, सत्यापित issues के लिए संबंधित documents में acknowledgement और credit दिया जाता है

अनुपयुक्त reports के लिए चेतावनी

• project ने साफ लिखा है: “अगर आप बेकार reports से समय बर्बाद करेंगे, तो आपको बैन किया जाएगा और सार्वजनिक रूप से आपका मज़ाक उड़ाया जाएगा”
  • यह गैर-पेशेवर या बिना आधार वाली reports को रोकने के लिए एक कड़ी चेतावनी है
  • यह report quality और responsible disclosure culture पर ज़ोर देता है

security reporting process और आधिकारिक जानकारी

• संपर्क माध्यम: ईमेल ([e-mail]) और GitHub Security Advisory page
• policy document: https://curl.se/dev/vuln-disclosure.html पर उपलब्ध
• acknowledgements page: https://curl.se/docs/security.html पर देखा जा सकता है
• preferred language: English (en)
• policy expiry date: 22 October 2026
• official URL: https://curl.se/.well-known/security.txt

[slowandsnow]

बेतरतीब ढंग से इश्यू उठाने की वजह से लगता है कि GitHub इश्यू पेज बंद कर देना ही सही जवाब है

[skageektp]

लगता है सार्वजनिक रूप से मज़ाक उड़ाना कोरियाई क़ानून के तहत अवैध नहीं है क्या, haha

[GN⁺]

Hacker News की राय

• हाल में देखा कि cURL ने AI द्वारा बनाए गए झूठे bug reports की बाढ़ आने के बाद bug bounty प्रोग्राम ही बंद कर दिया
  संबंधित लेख: Hacker News थ्रेड, ETN रिपोर्ट

  • अगर report, patch, और test case तक सही तरह से तैयार हों, तो भले ही वे AI-जनरेटेड हों, मुझे लगता है कि वे इनाम के लायक हैं

• अब सच में महसूस हो रहा है कि AI युग पूरी तरह आ चुका है

  • यह वही बात है जिसकी सबने उम्मीद की थी, बल्कि हैरानी इस बात की है कि यह इतना देर से फटा

• मुझे लगता है कि open source distribution model अब अस्थिर ढांचा बन गया है
  मूल रूप से free software movement का मकसद यह था कि users को खुद बदलाव और सुधार करने की आज़ादी मिले
  लेकिन अब issue tracker, PR review, email support, और security patch तक मुफ़्त में मिलने की उम्मीद करने वाली संस्कृति बन गई है
  यह असल में paid support work है, और अगर यह सिर्फ शौक नहीं है तो इसके लिए पारिश्रमिक होना चाहिए

  • मैंने पहले HapiJS से एक साधारण static site generator बनाया था और उसे GitHub पर डाला, लेकिन Reddit पर फैलते ही PR, bug reports, और गालियों की बाढ़ आ गई
    मैंने साफ कहा था कि “support देने का इरादा नहीं है,” फिर भी आलोचना बरसती रही, और वही मेरा पहला और आख़िरी OSS project था
  • मैं ऐसी system की कल्पना करता हूँ जहाँ users अपनी चाही गई features पर छोटा इनाम लगा सकें
    अगर कई users वही feature चाहें, तो reward pool बड़ा हो जाए, और developer उस काम को चुनकर पूरा करे
    project manager और tester भी एक तय हिस्सा लें, ताकि सबके पास प्रेरणा हो
  • मैं इस बात से सहमत नहीं हूँ कि open source के संस्थापकों ने ऐसा model कभी सोचा ही नहीं था
    Eric S. Raymond का “Bazaar model” और “Linus's Law (given enough eyeballs, all bugs are shallow)” तो मूल रूप से खुली collaboration पर ही आधारित हैं
  • मैं FOSS developers को पीड़ित की तरह देखने के नज़रिए से सहमत नहीं हूँ
    उन्हें खुद सीमाएँ और नियम तय करने चाहिए, और बदतमीज़ लोगों को block कर देना चाहिए
  • GitHub जैसे public issue trackers के ज़रिए collaboration अब दो पीढ़ियों से open source की मूल संस्कृति के रूप में स्थापित हो चुका है

• मैं हाल में OWASP documentation project में मदद कर रहा हूँ, और भारतीय छात्र LLM से बने अजीब PR और issues बड़ी मात्रा में डाल रहे हैं
  मैंने सुझाव दिया कि Ghostty की तरह पहले ‘Discussion’ से शुरुआत हो, और केवल maintainer द्वारा approve किए गए issues ही PR में बदले जाएँ

  • मैंने भारतीय developers में सवालों से बचकर सीधे आगे बढ़ जाने वाली ‘fake it till you make it’ संस्कृति देखी है
  • बहुत से छात्र resume के लिए GitHub activity दिखाने हेतु LLM code से PR भेजते हैं, लेकिन जब changes माँगे जाते हैं तो उन्हें कुछ समझ ही नहीं आता
    Torvalds ने जैसा कहा, LLM की वजह से code maintenance एक बुरे सपने जैसा हो जाएगा
  • जब ऐसे बेकार PR बढ़ जाते हैं, तो असली issues ढूँढना मुश्किल हो जाता है
  • मुझे लगता है कि Stack Overflow के पतन की एक वजह low-quality questions की बाढ़ भी थी

• एक बार मैंने bug report डाली थी, लेकिन reproduction details कम होने के कारण Reddit पर काफ़ी तीखी आलोचना झेलनी पड़ी
  उस घटना के बाद मैंने लगभग social media छोड़ ही दिया

  • curl team आमतौर पर विनम्रता से अतिरिक्त जानकारी माँगती है, इसलिए अगर सही जवाब नहीं दिया गया तो report बंद होना स्वाभाविक है
  • maintainers को ढेर सारी गलत reports में से असली bug ढूँढने के लिए बहुत मेहनत करनी पड़ती है
    यह याद रखना चाहिए कि आलोचना report की होती है, व्यक्ति की नहीं
  • curl team तो उल्टा काफ़ी उदार मानी जा सकती है, और Reddit पर हुई छींटाकशी का official community से कोई संबंध नहीं है
  • विडंबना यह है कि इस thread की प्रतिक्रिया भी “reproducible नहीं” वाले अनुभव पर ही चर्चा कर रही है

• Eternal September और LLM द्वारा पैदा की गई low-quality contributions की समस्या से निपटने के लिए शायद उल्टा entry barrier बढ़ाने वाला friction चाहिए
  जैसे, पहली contribution करने वाले को postcard पर QR code के साथ report भेजनी पड़े

  • लेकिन ऐसा friction कभी-कभी असली contributors से ज़्यादा spam contributors ही आसानी से झेल लेते हैं, इसलिए यह बेअसर भी हो सकता है

• अगर project emoji और errors से भरे PR में ही डूबा रहे, तो Bazaar model का चलना मुश्किल हो जाता है

  • इससे Brandolini’s Law याद आता है
    अप्रमाणित जानकारी की बाढ़ सिर्फ open source की नहीं, बल्कि पूरे समाज की समस्या है
    हमारी संस्कृति ने अभी तक झूठी जानकारी के खिलाफ प्रतिरक्षा तंत्र विकसित नहीं किया है

• इससे मुझे वह समय याद आता है जब The Pirate Bay MPAA की कानूनी धमकी वाले emails सार्वजनिक कर देता था
  TPB का legal response page (web archive) में उसका रिकॉर्ड देखा जा सकता है
  उनका तरीका बहुत प्रभावी तो नहीं था, लेकिन वह एक तरह का प्रतिरोध का प्रतीक बन गया था

• मेरे एक दोस्त के maintain किए जाने वाले मशहूर open source project पर चीनी विश्वविद्यालय के छात्र झूठी security vulnerability reports assignment के लिए जमा कर रहे हैं
  ज़्यादातर reproducible नहीं होतीं, इसलिए maintainer का समय बर्बाद होता है
  और अलग-अलग distributions की config differences के कारण कभी-कभी असली vulnerability upstream code में नहीं, बल्कि package settings में निकलती है
  Kryptos K4 subreddit में भी LLM द्वारा बनाई गई “solve कर दिया!” पोस्टों की भरमार है, इसलिए पहली ही गलती पर सीधे ban कर दिया जाता है
  यह चिंता की बात है कि AI homework cheating अब हर क्षेत्र में फैलती हक़ीक़त बन गई है

  • इंसान के रूप में हमें सीखने और बढ़ने की खुशी नहीं खोनी चाहिए
    AI कितना भी आगे बढ़ जाए, self-learning की value की जगह नहीं ली जा सकती
  • Kryptos K4 में, जबकि LLM के पास सारा data है, फिर भी वह एक भी नया idea नहीं दे पाता
    आखिरकार LLM creative thinking नहीं, बल्कि एक upgraded autocomplete tool भर है
  • चीन में medical students द्वारा papers खुद लिखने के बजाय ghostwriting के ज़रिए academic journals को प्रदूषित करना आम बात बताई जाती है
  • अंत में academic cheating बाज़ार तक पहुँचती है, और जब तक financial incentives बने रहेंगे, यह रुकने वाली नहीं है

• मुझे लगता है कि GitHub को users के लिए trust score या reputation system देना चाहिए

  • लेकिन GitHub अब AI division (Microsoft CoreAI) के तहत है, इसलिए संभव है कि वह ऐसे व्यवहार को उल्टा प्रोत्साहित करे
    संबंधित लेख: GeekWire रिपोर्ट
  • developers को social score देना Microsoft की तरफ़ से एक डरावना विचार होगा
  • मुझे तो इससे बेहतर यह लगता है कि users को anonymous बनाया जाए, ताकि प्रतिष्ठा पाने की प्रेरणा कम हो
  • HackerOne जैसे platforms में reputation system होने के बावजूद low-quality reports की भरमार रहती है
    अंत में कंपनियाँ paid triage services लेने लगती हैं
    इस प्रक्रिया में अक्सर असली विशेषज्ञ नहीं, बल्कि कोई और पहले जवाब देता है, जिससे genuine reports के निपटने में देरी होती है
    मौजूदा स्थिति सबके लिए खराब ढांचा है और लगातार बिगड़ती जा रही है