- curl मेंटेनेंस अब सार्वजनिक हित, इंजीनियरिंग चुनौती और गुणवत्ता लक्ष्यों का मिला-जुला एक फुल-टाइम काम बन चुका है, और यह लगभग सप्ताह में 50 घंटे तक चलता रहा है
- curl लगभग 30 अरब इंस्टॉल बेस वाली एक ट्रांसफर लाइब्रेरी और टूल है, इसलिए इस बात का दबाव बहुत बड़ा है कि कोई सुरक्षा विफलता उपयोगकर्ताओं तक न फैले
- अभी सुरक्षा रिपोर्टों का प्रवाह 2024 की तुलना में 4~5 गुना और 2025 के मुकाबले दोगुना है, और औसतन रोज़ एक से अधिक रिपोर्ट आती हैं, इसलिए तुरंत कार्रवाई ज़रूरी है
- सुरक्षा कार्य में दावों की पुष्टि, गंभीरता का आकलन, पैच लिखना, यह पता लगाना कि समस्या कब आई, सलाह जारी करना, और शोधकर्ताओं व सुरक्षा टीम से संवाद शामिल है
- अगली नियोजित रिलीज़ तक पहले से ही 12 पुष्ट कमजोरियां लंबित हैं, और इस अभूतपूर्व दबाव के बीच फंडिंग और जनशक्ति सहायता की सीमाएं साफ़ दिख रही हैं
curl के प्रति जिम्मेदारी और दीर्घकालिक मेंटेनेंस
- ओपन सोर्स काम पैसा या चमकदार जीवन के लिए नहीं, बल्कि सामाजिक महत्व, सार्वजनिक हित और ऐसी इंजीनियरिंग चुनौती की वजह से जारी रहता है जो हर किसी के लिए काम करे
- curl पर काम 2019 से फुल-टाइम हो गया, और आम तौर पर इसमें हफ्ते के लगभग 50 घंटे लगते हैं, जिनमें दिन, देर रात, कार्यदिवस और सप्ताहांत सब शामिल हैं
- curl का लक्ष्य संभवतः सबसे बेहतरीन ट्रांसफर लाइब्रेरी और टूल बनना है, और ओपन सोर्स गुणवत्ता, प्रदर्शन और सुरक्षा के लिहाज़ से शीर्ष परियोजनाओं में शामिल होना है
- curl किसी एक व्यक्ति की परियोजना नहीं है, और टीम के सदस्यों के बिना आज का curl संभव नहीं होता, लेकिन फिर भी बहुत से लोग curl को Daniel Stenberg व्यक्ति से गहराई से जोड़कर देखते हैं
- curl पर की गई आलोचना अक्सर उन फैसलों और विकल्पों पर की गई आलोचना जैसी लगती है जिन्हें स्वयं समर्थन दिया गया हो या स्वयं लिया गया हो, और curl एक ऐसी निजी परियोजना बन चुका है जिसने जीवन को स्थायी रूप से बदल दिया है
- 2026 के अंत में curl परियोजना 30वीं वर्षगांठ मनाएगी, और दुनिया भर में curl इंस्टॉलेशन की संख्या लगभग 30 अरब बताई जाती है
सुरक्षा रिपोर्टिंग माहौल में बदलाव
- पिछले कुछ वर्षों में curl सुरक्षा रिपोर्टिंग का माहौल मूर्खतापूर्ण LLMs पर शिकायतों से बदलकर AI स्लोप रिपोर्ट्स, bug bounty का अंत, और 2026 के मार्च के आसपास शुरू हुई उच्च-गुणवत्ता वाली अव्यवस्था तक पहुंच गया है
- जब भी इंटरनेट उत्पादों, सॉफ़्टवेयर इंफ्रास्ट्रक्चर और ओपन सोर्स में बड़ी सुरक्षा विफलताएं बार-बार होती हैं, तब यह तथ्य कि curl हर जगह मौजूद है, और ऐसा कुछ curl या उसके उपयोगकर्ताओं के साथ नहीं होना चाहिए, दबाव को और बढ़ा देता है
- curl परियोजना ने और अधिक जांच, टेस्ट और दिशानिर्देश जोड़ते हुए धीरे-धीरे इस संभावना को कम किया है कि कोई खामी निकल जाए या डूब जाए
उच्च सत्यापन स्तर और फिर भी बचा जोखिम
- Mythos ने पहली स्कैन में केवल एक low severity समस्या पाई वाली घटना के बाद से बार-बार कहा गया है कि curl शायद कल्पना की जा सकने वाली सीमाओं तक सबसे अधिक समीक्षा, fuzzing और सत्यापन किए गए कोड में से एक है
- यह स्थिति संयोग या किस्मत का परिणाम नहीं, बल्कि दशकों की जिद्दी मेहनत, बारीकियों पर ध्यान और कभी खत्म न होने वाले दोहराए जाने वाले सुधार का नतीजा है
- बहुत अधिक समीक्षा और सत्यापन का मतलब यह नहीं कि बग या सुरक्षा समस्याएं नहीं होंगी; curl कई प्रोटोकॉल, ऑपरेटिंग सिस्टम और CPU आर्किटेक्चर पर अत्यधिक समानांतर नेटवर्किंग करने वाला C कोड का सैकड़ों हजार लाइनों वाला कोडबेस है
- जब भी समस्याएं मिलती हैं, उन्हें ठीक किया जाता है और पैच रिलीज़ किए जाते हैं
- लगभग 30 अरब का वैश्विक इंस्टॉल बेस यह भी दर्शाता है कि फ़ोन, टैबलेट, कार, TV, प्रिंटर, गेम कंसोल और रसोई उपकरणों में curl कई बार शामिल हो सकता है
- अतीत में जिन परियोजनाओं ने बड़े बग्स के कारण कुछ समय के लिए दुनिया भर में हलचल मचा दी, उन्हें ध्यान मिला, और कुछ को फंडिंग व लोग भी मिले, जिससे वे कई फुल-टाइम इंजीनियर रख सके
अभूतपूर्व सुरक्षा रिपोर्टों की मात्रा
- अभी सुरक्षा रिपोर्टों का आने का वेग 2024 की तुलना में 4~5 गुना अधिक है, 2025 का दोगुना है, और औसतन हर दिन एक से अधिक रिपोर्ट आती है
- रिपोर्टों की गुणवत्ता पहले से कहीं बेहतर है, और वे आम तौर पर बहुत विस्तृत और लंबी होती हैं
- चूंकि रिपोर्टें लगातार आती रहती हैं, इसलिए संभव हो तो उन्हें आते ही संभालना पड़ता है; यदि निपटान की रफ्तार आगमन की रफ्तार के बराबर न रहे, तो संभावित सुरक्षा समस्याओं की सूची लगातार बढ़ती जाती है
- ऐसी संभावित सुरक्षा समस्याओं की सूची जिसे नियंत्रित न किया जा सके, मानसिक बोझ पैदा करती है
- फिलहाल अधिकांश समय HackerOne पर रिपोर्ट किए गए सुरक्षा मुद्दों की सूची संभालने में जाता है
- मुख्य कामों में दावों की पुष्टि, गंभीरता का आकलन, पैच लिखना, यह पता लगाना कि बग कब शामिल हुआ, कमजोरी को समझना, विस्तृत सुरक्षा advisory लिखना, और सुरक्षा शोधकर्ताओं व curl सुरक्षा टीम के साथ संवाद करना शामिल है
स्वास्थ्य और टीम पर दबाव
- पहली बार जीवनसाथी ने काम के घंटों और असंतुलित work-life स्थिति को लेकर चिंता जताई, और आसपास के लोग भी इस भारी प्रवाह को कैसे संभाला जा रहा है और burnout की संभावना को लेकर चिंतित हैं
- टीम के सदस्यों को लेकर चिंता भी बढ़ गई है, और शायद जल्द ही सांस लेने की गुंजाइश बनाने के लिए काम के घंटे घटाने पड़ सकते हैं
- मौजूदा स्थिति curl परियोजना और सुरक्षा टीम के सदस्यों पर ऐसा दबाव है जैसा उन्होंने पहले कभी नहीं झेला
- सुरक्षा मुद्दों का निपटारा परियोजना के बाकी सभी कामों पर भारी पड़ने वाला सर्वोच्च प्राथमिकता वाला काम है, और जिम्मेदारी, अंतरात्मा और काम पर गर्व के कारण इसे नज़रअंदाज़ नहीं किया जाता
- चूंकि curl दुनिया भर के उपकरणों में तैनात सॉफ़्टवेयर है, इसलिए उसके भीतर की सुरक्षा समस्याओं को ठीक करना एक गहरी जिम्मेदारी जैसा महसूस होता है
- नियोजित रिलीज़ तक, जबकि रिलीज़ चक्र का लगभग आधा समय अभी बाकी है, पहले से ही 12 पुष्ट कमजोरियां मौजूद हैं, यानी 12 लंबित CVE घोषणाएं
- यह परियोजना का नया रिकॉर्ड है, और इसका मतलब है कि 2026 आधा भी खत्म होने से पहले सार्वजनिक CVE की संख्या 30 तक पहुंच जाएगी
- यदि यही रुझान जारी रहा, तो 2026 में curl के कुल सार्वजनिक CVE कम से कम उसके दोगुने होने की उम्मीद है
आवश्यक सहायता और संरचनात्मक सीमाएं
- अल्पावधि में, निपटाने के लिए पहले से ही इतना काम है कि तुरंत मदद मिलना अब शायद बहुत देर हो चुकी अवस्था है
- यदि वे कंपनियां जो commercial software और services में curl या libcurl का उपयोग और उस पर निर्भर करती हैं, अधिक फंडिंग दें, तो अधिक डेवलपर्स को भुगतान करके काम का बोझ बांटा जा सकता है
- support contracts के ज़रिए नियोक्ताओं से भुगतान करवाना भी सहायता का एक संभव रास्ता है
- ऐसे ग्राहक पहले से मौजूद हैं, जिनकी सहायता से कुछ सदस्य curl पर फुल-टाइम काम कर पा रहे हैं
- फिर भी इस क्षेत्र में जल्द किसी अर्थपूर्ण बदलाव की उम्मीद नहीं है, और यह संभव है कि अभूतपूर्व स्थिति और अधिक कठिन दौर में भी अंततः इस तूफ़ान को खुद ही पार करना पड़े
- curl परियोजना किसी कंपनी की मालिकाना परियोजना नहीं है और न ही किसी umbrella organization का हिस्सा है
- ऐसी संरचना कभी-कभी संसाधनों की कमी पैदा करती है, लेकिन साथ ही अधिकतम स्वतंत्रता और लचीलापन भी देती है
- परियोजना का आचरण सिद्धांत इस बात पर केंद्रित है कि दुनिया और curl उपयोगकर्ताओं के लिए curl को जितना संभव हो उतना बेहतर बनाया जाए
सकारात्मक पक्ष और मौजूदा स्थिति
- बग्स और समस्याओं को ठीक करना अपने आप में अच्छी बात है, और रिपोर्ट हुई हर समस्या का मतलब है कि एक और मुद्दा जल्द सुधरेगा
- जितनी अधिक रिपोर्टें आती हैं, curl उतना बेहतर उत्पाद बनता है
- पिछले कुछ वर्षों में खोजी गई curl कमजोरियों को सभी को LOW या MEDIUM severity दी गई है, और बहुत गंभीर कमजोरियां लगभग नहीं मिली हैं
- इसका मतलब यह नहीं कि आगे फिर कभी HIGH नहीं आएगा, लेकिन कम-से-कम अभी यह दुर्लभ है
- curl का सबसे हाल का high severity CVE अक्टूबर 2023 में सार्वजनिक किया गया CVE-2023-38545 है
- फिलहाल curl टीम दबाव में है, और कभी-कभी उसकी प्रतिक्रिया धीमी हो सकती है
1 टिप्पणियां
Lobste.rs की राय
उम्मीद है कि Daniel और बाकी लोग स्वास्थ्य या परिवार पर बड़ा बुरा असर डाले बिना इस मुश्किल स्थिति से अच्छी तरह निकल जाएंगे
हालांकि यह मामला कैसे आगे बढ़ेगा, यह काफ़ी दिलचस्प होगा। कई FOSS प्रोजेक्ट्स में नई automated analysis तकनीकों द्वारा अचानक बहुत सारी vulnerabilities ढूंढ लेना पहली बार नहीं हुआ है, और अभी माहौल कुछ वैसा ही लग रहा है जैसा 2010s में graybox fuzzing के आने पर था। संभावित रूप से तीन दिशाएं दिखती हैं: A) डेवलपर्स LLM को security research workflow में शामिल कर लेते हैं, जिससे LLM द्वारा मिलने वाली नई vulnerabilities की संख्या काफ़ी घट जाती है, और LLM की पहुंच से बाहर वाली vulnerabilities वैसे ही मिलती रहती हैं जैसे fuzzer scenario में। B) A जैसा ही, लेकिन LLM सब स्कैन कर लेने के बाद vulnerability discovery लगभग रुक जाती है — यानी “LLM security research को solve कर देता है” वाला scenario। C) curl जैसे बड़े प्रोजेक्ट्स में vulnerabilities लगातार ऊंची दर से मिलती रहती हैं, और सैकड़ों हज़ार lines of code वाले प्रोजेक्ट्स में bugs की संख्या practically infinite होती है — यह “Tony Hoare का revenge” scenario है
किसी खास codebase के snapshot में security bugs की संख्या सीमित ही हो सकती है। जब security bug search space ख़त्म होने लगेगा तो यह बाढ़ कम हो जाएगी, और उसके बाद code merges, नए test harnesses, या model improvements से आने वाले bugs थोड़ा-थोड़ा करके बचे रहेंगे
curl प्रोजेक्ट के C scenario के बारे में, मेरा मानना है कि पहले से security testing और पारंपरिक bug-finding techniques का स्तर इतना ऊंचा था कि जो bugs मिले वे कम severity वाले थे। यह दिखाता है कि bug-finding में लगातार निवेश लंबे समय में फ़ायदा देता रहता है। आज हो या भविष्य में, discovery method कोई भी हो, बात वही है
Marcus Hutchins के शब्दों में, “bottleneck bug finding कभी नहीं था, bottleneck यह था कि organizations ने security researchers में निवेश न करने का फैसला किया।” LLM ने बस उस निवेश को सस्ता बना दिया है, जबकि organizations पहले भी ज़्यादा निवेश करके और bugs ढूंढ सकती थीं। आख़िरकार यह policy decision है
LLM technology बनाने वाली कंपनियां सिर्फ़ प्राकृतिक दुनिया ही नहीं बल्कि software world को भी बर्बाद कर रही हैं। hardware की कीमतें इतनी बढ़ रही हैं कि personal computing itself भी खतरे में है, और वे अच्छे open source developers भी जो सिर्फ़ बनाने की इच्छा से बनाते हैं
यह दिलचस्प है कि पुराने community-managed open source projects को कमजोर और बर्बाद करने के लिए जैसे अनंत फंड मौजूद है, लेकिन उसके बाद के fallout से निपटने के लिए ज़रा भी पैसा नहीं है
मेरा मानना है कि यह साबित करता है कि Zig सही था। LLM द्वारा खोजे गए CVE को बस संभालना ही नहीं चाहिए; जिसे करना हो, वह करे
मुझे पता है कि मुद्दा बिल्कुल यही नहीं है, लेकिन LLM CVE की समस्या यह है कि वही tool इस्तेमाल करने वाला कोई और भी शायद वही चीज़ ढूंढ लेगा। अगर सच में कोई गंभीर issue मिलता है, तो इसका मतलब है कि और लोग उससे नुकसान पहुंचाने वाली चीज़ें भी बना सकते हैं
बेशक इसका मतलब यह नहीं कि curl में आने वाले ढेर सारे low-severity या non-security issues पर यही बात वैसे ही लागू होती है। फिर भी, किन issues को high priority देना है, यह तय तो करना ही पड़ेगा, और तब हम फिर से पहले चरण पर लौट आते हैं
Zig अभी भी सक्रिय development में है, और उदाहरण के लिए जब भी incremental compilation या asynchronous I/O जैसी features को ठोस रूप दिया जाता है, नए bugs आने की संभावना रहती है, साथ ही पुराने implementation की अपूर्णता से बने bugs भी हट जाते हैं
development के इस चरण में अगर कोई Mythos जैसी चीज़ Zig पर चलाकर “सारे bugs ढूंढो और गलती मत करो” वाली approach अपनाए, तो reports की बहुत बड़ी मात्रा निकल सकती है, लेकिन संभव है कि वह लगभग पूरी की पूरी हमारे लिए बेकार हो। अभी bug reports की मुख्य value यह संकेत देने में है कि किसी खास use case में कोई user blocked है, और अगर हम priority देने का निर्णय लें, तो हम उस user की समस्या दूर कर सकते हैं
इसका मतलब यह नहीं कि यह स्थिति हमेशा रहेगी। कई महत्वपूर्ण compiler features अब align हो रही हैं, और जब stabilization होगी, तब सभी bugs ढूंढना और ठीक करना सबसे ऊंची priority बन जाएगा। उस समय यह तथ्य महत्वपूर्ण होगा कि bug जाना-पहचाना है, चाहे वह कैसे भी मिला हो, लेकिन उस समस्या को हम उसी समय संभालेंगे
तब तक की policy बस LLM ban है
LLM contributions पर ban समझ में आता है, लेकिन मैं उससे सहमत नहीं हूं। security vulnerabilities, उन्हें कैसे खोजा गया उससे अलग, vulnerabilities ही हैं
मुझे लगता है Daniel का तरीका सबसे अच्छा है। जो bugs ठीक किए जा सकते हैं उन्हें ठीक करो ताकि users ज़्यादा सुरक्षित हों, और साथ ही यह भी बताओ कि इसकी लागत बड़ी है तथा support मांगो। शायद वह यह पोस्ट कभी न पढ़े, लेकिन मैं यह समर्थन और सुझाव भी देना चाहूंगा कि वह physical और mental health को प्राथमिकता देने के लिए workload सीमित करे। दुनिया के ज़्यादातर लोग इसे समझेंगे, और शिकायत शायद बहुत कम लोग करेंगे
यहां दो मुख्य बातें गायब लगती हैं। 1) LLM कंपनी या Project Zero ने वह security bug code में डाला नहीं था। 2) security bug fix करना LLM कंपनी या Project Zero के लिए नहीं बल्कि users के लिए होता है। security bug exploit होने पर नुकसान users को होता है
खासकर LLM द्वारा खोजे गए bugs के मामले में, पहले से संकेत हैं कि अलग-अलग open source projects में उसी LLM का इस्तेमाल करने वाले दूसरे लोग duplicate reports भेज रहे हैं। इसलिए अगर defenders हाथ खींच लें, तो हमें मान लेना चाहिए कि attackers भी LLM-discovered bugs के बारे में जान जाएंगे
“मुझे उन projects से ईर्ष्या होती है जिन्होंने अतीत में ऐसे भयानक bugs ship किए जिन्होंने कुछ समय के लिए दुनिया को जला दिया। उन्हें attention मिला, और कुछ को funding और financial power भी मिली, जिससे वे staff रख सके और कई full-time engineers hire कर सके। कभी-कभी मुझे लगता है कि अगर हमारे पास भी ऐसा एक मामला होता, तो शायद हमारे लिए बेहतर होता”
ऐसा बहुत-सी workplaces में भी होता है। जो teams fail होती हैं उन्हें ज़्यादा लोग मिलते हैं, और जो teams अच्छा करती हैं उन्हें कम लोगों से ज़्यादा काम करना पड़ता है क्योंकि उनके यहां कोई भयानक घटना नहीं हुई
पता नहीं यह curl जैसे project पर फिट बैठता है या नहीं, लेकिन क्या कुछ समय के लिए feature freeze करके सिर्फ़ आने वाली bug/CVE reports पर focus करना मददगार होगा?
अगर feature set तय है, तो संभावित bugs/CVE की संख्या सीमित होनी चाहिए, और उन्हें ठीक करते-करते संख्या 0 के क़रीब पहुंचनी चाहिए
फिर भी, उन्हें शुभकामनाएं। इतने महत्वपूर्ण software को maintain करने का यह दौर आसान नहीं होगा
developer satisfaction पर इसका असर क्रमशः बढ़ता, बना रहता, और घटता है
feature freeze release को अच्छी तरह पूरा करने के लिए एक शानदार tool है, लेकिन अपने दम पर दिशा तय करके काम करने वाले डेवलपर्स पर दबाव कम करने के लिए यह अच्छा tool नहीं है