curl के सुकूनभरे गर्मियों के दिन
(daniel.haxx.se)- ओपन सोर्स curl प्रोजेक्ट जुलाई 2026 के पूरे महीने vulnerability reports स्वीकार करने और उन पर काम करने को रोक देगा, ताकि maintainers को आराम का समय मिल सके
- HackerOne submission form 1 जुलाई 2026 00:00 CEST से बंद रहेगा और 3 अगस्त 2026 09:00 CEST पर फिर से खुलेगा
- security email address पर भेजी गई security और vulnerability reports भी process नहीं की जाएंगी, और curl आम तौर पर email के जरिए vulnerability reports स्वीकार नहीं करता
- इस कदम की वजह से 8.22.0 release schedule 2 हफ्ते आगे खिसककर 2 सितंबर 2026 कर दिया गया है
- paid support contract वाले users को इस दौरान भी पूरी service मिलेगी, और GitHub के issue व pull request trackers हमेशा की तरह खुले रहेंगे
मुख्य समय-सारिणी और लागू दायरा
- curl के सुकूनभरे गर्मियों के दिन के दौरान curl प्रोजेक्ट जुलाई 2026 के पूरे महीने किसी भी vulnerability report को न तो स्वीकार करेगा और न ही process करेगा
- शुरुआत का समय 1 जुलाई 2026 00:00 CEST है
- submission दोबारा शुरू होने का समय 3 अगस्त 2026 09:00 CEST है
- HackerOne submission form 1 जुलाई 2026 से बंद रहेगा, और सोमवार 3 अगस्त को फिर से submission के लिए उपलब्ध होगा
- security email address भी इस अवधि में security और vulnerability reports के लिए processing channel नहीं रहेगा
- अगर आपको लगे कि इस दौरान curl प्रोजेक्ट को कोई issue report करना चाहिए, तो उसे इंतज़ार करना होगा
- curl आम तौर पर email से vulnerability reports स्वीकार नहीं करता, और यह बात छुट्टी की अवधि में भी और उसके बाद भी लागू रहेगी
संचालन पर असर और अपवाद
-
असली छुट्टी
- curl maintainers इस कम दबाव वाले समय का उपयोग गर्मियों का आनंद लेने, बाहर ज़्यादा घूमने और थोड़ा आराम करने के लिए करेंगे
- कुछ maintainers इस दौरान किसी और जगह भी जा सकते हैं
- bug fixes या नए code पर काम करने के लिए अतिरिक्त समय भी मिल सकता है, और इसे मज़ेदार काम माना जाता है
-
दुष्प्रभाव
- अगस्त की शुरुआत में जमा हो सकने वाले मुद्दों को संभालने का समय सुनिश्चित करने के लिए 8.22.0 release की तारीख 2 हफ्ते आगे बढ़ा दी गई है
- 8.22.0 अब फिलहाल 2 सितंबर 2026 को release होने वाला है
-
vulnerability reports में बढ़ोतरी
- curl प्रोजेक्ट पिछले लगभग 4 महीनों से काफी दबाव में रहा है
- अभी आराम की ज़रूरत है, और यह उम्मीद नहीं है कि ऐसी भारी संख्या में आने वाली reports रुक जाएंगी
-
GitHub
- curl के issues और pull requests trackers GitHub पर हमेशा की तरह खुले और सक्रिय रहेंगे
-
दूसरे open source projects
- अगर दूसरे open source projects भी 2026 के सुकूनभरे गर्मियों के इस दौर में शामिल होना चाहते हैं, तो वे बस इसे लागू करें और curl को बता दें
- खुद की देखभाल को सबसे ऊपर रखना प्रोत्साहित किया जाता है
-
बुरे लोग आराम नहीं करते
- बुरे लोग शायद आराम न करें, लेकिन curl maintainers करेंगे
-
आपात स्थिति
- आपात स्थिति होने पर भी curl maintainers उसे अगस्त में ही पढ़ेंगे
- उससे पहले पढ़वाने के लिए support contract चाहिए
-
contract अपवाद
- paid support contract वाले सभी लोगों को इस अवधि में भी पूरी और उचित service मिलती रहेगी
2 टिप्पणियां
Hacker News की राय
शीर्षक ने असली बात को दबा दिया। यह गर्मी की छुट्टी लेने के साथ-साथ लगातार सपोर्ट पाने के लिए enterprise support contract को भी बढ़ावा देने का तरीका है
open source/सपोर्ट/गर्मी की छुट्टी को इस तरह जोड़ने वाला business model मैंने शायद पहली बार सुना है, और यह पसंद आया
open source को ज्यादा फंडिंग मिलेगी, और कंपनियों को किसी खास open source के लिए full-time कर्मचारी रखने की तुलना में सस्ता सपोर्ट मिल सकेगा
“बुरे लोग आराम नहीं करेंगे, लेकिन हम करेंगे” वाली बात अमानवीय समय में सुखद इंसानीपन देती है
कुछ ऐसा: “support contract साइन करो, तो हम इसे पहले पढ़ेंगे”
जो लोग छुट्टी के दौरान सचमुच काम से पूरी तरह कट जाना चाहते हैं, उनके लिए बेहतर है कि वे खुद को काम करने में असमर्थ बना लें
work device पीछे छोड़ दें, सभी accounts से log out कर दें, 2FA key को कागज़ पर backup करके हटा दें, और छुट्टी के दौरान partner से उसे वापस न दिलवाएँ। मैं तो एक बार ऐसे देश भी गया हूँ जहाँ remote work allowed नहीं था। पागलपन लगता है, लेकिन मामला इतना गंभीर था। यह एक पूर्व workaholic लिख रहा है
जर्मनी में अगर आप छुट्टी पर हैं, तो बस आपसे संपर्क नहीं हो सकता। लौटने तक आपको दुनिया से गायब माना जाता है, आप email भी नहीं पढ़ते, और device भी office में छोड़ देते हैं। और अगर छुट्टी के दौरान बीमार पड़ जाएँ, तो छुट्टी के दिन वापस मिल जाते हैं, क्योंकि छुट्टी का मकसद आराम और recovery है
अगर कंपनी आने-जाने का समय सख्ती से गिने, हर 30 मिनट के निजी काम के लिए paid leave लेने को कहे, या काम लगातार हफ्ते के 40 घंटे से ऊपर जाने लगे, तो मैं भी “काम के बाहर” वाला काम बंद कर दूँगा। लेकिन अगर कंपनी reasonable है, तो मैं भी reasonable रह सकता हूँ
छिपे हुए bus factor को ढूँढने के लिए यह शानदार tool था
20 accounts में log in/log out करने की ज़रूरत नहीं पड़ेगी
पहले मैं अपने personal laptop या desktop से VPN+RDC के जरिए office desktop में connect करके remote काम कर सकता था। अब मुझे एक laptop मिला है, लेकिन remote authentication काम नहीं करता, और कंपनी की दूसरी priorities हैं इसलिए वे इसे ठीक करने वाले भी नहीं। नतीजा यह है कि अगर वह laptop साथ न हो, तो मैं काम कर ही नहीं सकता, और जब मैं पहले से personal device साथ ले जा रहा हूँ, तो company laptop भी लेकर नहीं घूमता। और अगर personal device भी साथ नहीं है, तो वैसे भी कोई laptop ले जाने का सवाल नहीं उठता
मैं खुद को workaholic नहीं मानता, लेकिन अगर मुझे लगे कि मैं मदद कर सकता हूँ, तो मैं 24 घंटे stress लेता रहता हूँ। office के बाहर बिल्कुल काम न कर पाने की बात सचमुच मदद करती है। सचमुच मैं कुछ कर ही नहीं सकता, और खासकर जब कंपनी ने खुद हालात ऐसे बनाए हों, तो उसी तरह stress भी नहीं होता
[1] VPN dongle और पुराने phone पर MFA device के अलावा, Teams हो या email, काम से जुड़ी कोई भी चीज़ मेरे personal device तक नहीं पहुँचती
[2] मैंने factory reset किए हुए एक छोटे पुराने phone में सिर्फ dummy Google account और MFA app install कर रखा है
libexpat (“Expat”) और uriparser भी curl की security vacation का पालन कर रहे हैं, और आज से 2026-08-01 तक नई vulnerability reports स्वीकार नहीं करेंगे
[1] https://github.com/libexpat/libexpat/issues/1277
[2] https://github.com/uriparser/uriparser/issues/323
जिन्हें लगता है कि इसका security पर असर पड़ सकता है, उनके लिए: curl इतना mature है कि बड़े असर वाले bug की संभावना लगभग शून्य के बराबर है, और अगर ऐसा bug हुआ भी, तो कोई न कोई Daniel और उनकी टीम तक पहुँचने का तरीका ढूँढ ही लेगा; उससे भी ज़्यादा अहम यह है कि patch package manager तक पहुँचे और deploy हो
upstream release इंतज़ार कर सकती है
सिर्फ arbitrary data को shell तक डाउनलोड करना भी environment के बाकी हिस्सों में किसी vulnerability को गलती से trigger कर सकता है
इस फैसले की तारीफ किए बिना नहीं रह सकता। free open source project maintainers लगभग बिना किसी मुआवज़े के लगातार overloaded रहते हैं, और अब LLM की वजह से merge request संभालने का बोझ और भी विस्फोटक रूप से बढ़ गया है
paid users को वे सपोर्ट देते रहेंगे, सिर्फ यही बात काफी है
मेंटेनर्स के प्रति सहानुभूति है, लेकिन आखिरकार यह फिर सामने आ गया कि हम लगभग मुफ़्त में काम करने वाले कुछ लोगों पर बिना किसी बैकअप के निर्भर हैं
आम तौर पर संगठन ऐसी स्थिति से बचने के लिए छुट्टियां अलग-अलग समय पर तय करते हैं। ग्राहकों की मांग के कारण उन्हें ऐसा करना पड़ता है। यहां curl के ग्राहक तो सब हैं, लेकिन वास्तविकता में ऐसा भी नहीं है। यह एक अजीब और अस्वस्थ ग्रे ज़ोन लगता है जो किसी के लिए अच्छा नहीं है। यह बात चौंकाने वाली और दुखद भी है कि curl के पास एक महीने तक ऑन-कॉल रखने की वित्तीय क्षमता भी नहीं है
यह रिश्ता तभी अस्वस्थ होता है जब कोई वारंटी नहीं को अवास्तविक अपेक्षाओं के साथ मिलाकर उस पर थोप दिया जाता है
लेख का सार भी यही लगता है कि अगर support चाहिए, तो support contract खरीदिए
“paid support contract वाले सभी लोगों को, बेशक, इस अवधि में भी पूरी और उचित सेवा मिलती है” ऐसा लिखा है
vulnerabilities को लगातार ढूंढना, रिपोर्ट करना, उनका विश्लेषण करना, फिर patch करना, और नया version सभी users तक पहुंचाना—यह मौजूदा सिस्टम साफ़ तौर पर टिकाऊ नहीं है
इंडस्ट्री को bugs और security issues से निपटने के लिए कोई वैकल्पिक सिस्टम ढूंढना होगा। अभी इंडस्ट्री अनजान बनने और अपनी नाकामी को rent-seeking के अवसर में बदलने को ज़्यादा पसंद करती है
और open source में जिस rent-seeking की बात की गई, उसके उदाहरण क्या हैं?
सिर्फ़ एक वाक्य पढ़कर ही समझ गया कि डेवलपर स्वीडिश होगा
संदर्भ: https://www.riksdagen.se/sv/dokument-och-lagar/dokument/sven...
अमेरिका में भी ऑफिस है, और अमेरिकियों को जो cultural shock मिलता है, वह हर बार नया लगता है
यूरोप में, जैसे जर्मनी में, 20~30 दिन का paid vacation और असीमित sick leave सामान्य है। sick leave 3 दिन से ज़्यादा हो तो डॉक्टर का note चाहिए
अगर आप छुट्टी के दौरान बीमार पड़ते हैं, तो वे छुट्टी के दिन आपको वापस मिलते हैं। अगर छुट्टी के दौरान अचानक काम करना पड़ जाए, तो वह समय छुट्टी का समय नहीं माना जा सकता। आम तौर पर आपको बिना notice period के निकाला नहीं जा सकता, इसलिए नौकरी की स्थिरता ज़्यादा होती है, और नौकरी चली भी जाए तो unemployment support मिलता है, इसलिए करीब 6,000 डॉलर की emergency fund के साथ भी काफ़ी स्थिरता रहती है। क्या इससे अक्षम लोग निकाले नहीं जाते? ऐसा नहीं है। उन्हें अब भी निकाला जा सकता है, बस उसके बाद लगभग एक महीना और झेलना पड़ता है। यह कोई बहुत बड़ी कीमत नहीं है
यह कैसे संभव है और सब्सिडी कौन देता है? बस सभी लोग अपनी आय का कुछ प्रतिशत देकर इस सिस्टम को बनाए रखते हैं। उन कुछ प्रतिशत, कुछ डॉलर की वजह से आपको भूख या बेघर होने की चिंता लगभग नहीं करनी पड़ती
आप भी वोट कर सकते हैं, विरोध कर सकते हैं, और लोकतंत्र का इस्तेमाल करके सबकी ज़िंदगी को बदतर नहीं बल्कि बेहतर बना सकते हैं
Lobste.rs की राय
“बुरे लोग कभी आराम नहीं करते”, लेकिन फिर भी हमें आराम करना चाहिए
उम्मीद है कि आप छुट्टियाँ अच्छी तरह बिताएँगे, और आप इसके पूरी तरह हकदार हैं। जो दूसरे लोग दबाव महसूस कर रहे हैं, वे भी छुट्टी लेने पर विचार करें तो अच्छा होगा
बुरे लोग vulnerability report भेजने वाले भी नहीं हैं, इसलिए इंतज़ार करते रहने से इस खतरे में कोई फर्क पड़ता नहीं दिखता
व्यक्तिगत रूप से मुझे 4 हफ्ते की छुट्टी भी थोड़ी छोटी लगती है, लेकिन हो सकता है मैं कुछ ज़्यादा ही फ़्रांसीसी अंदाज़ में सोच रहा हूँ
आम तौर पर जुलाई में स्वीडन की मैन्युफैक्चरिंग फैक्ट्रियाँ ज़्यादातर कर्मचारियों को छुट्टी देती थीं, और उसी दौरान फैक्ट्री की जाँच, मेंटेनेंस और मरम्मत होती थी। आज भी बहुत से लोग midsummer के बाद एक महीने के भीतर अपनी सालाना छुट्टी रखना चाहते हैं, और क़ानूनी रूप से midsummer day 20~26 जून के बीच का शनिवार होता है
उम्मीद है वे छुट्टी का आनंद लें :)
लेकिन हो सकता है उन्हें पता ही न चला हो कि वह पोस्ट जिसमें Mythos ने बड़े दबे स्वर में शेखी बघारी कि उसे सिर्फ एक bug मिला ने छत्ते में हाथ डाल दिया
यह देखना अच्छा लगता है। उम्मीद है इससे दूसरे open source maintainers को भी अपनी भलाई को प्राथमिकता देने की प्रेरणा मिलेगी
अच्छा लगा। काश दूसरे projects भी यही तरीका अपनाएँ