2 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • ओपन सोर्स 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 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय
  • शीर्षक ने असली बात को दबा दिया। यह गर्मी की छुट्टी लेने के साथ-साथ लगातार सपोर्ट पाने के लिए enterprise support contract को भी बढ़ावा देने का तरीका है
    open source/सपोर्ट/गर्मी की छुट्टी को इस तरह जोड़ने वाला business model मैंने शायद पहली बार सुना है, और यह पसंद आया

    • यह आइडिया अच्छा लगा, और open source भी 6 महीने public support + 6 महीने enterprise support जैसा शेड्यूल अपना सकता है
      open source को ज्यादा फंडिंग मिलेगी, और कंपनियों को किसी खास open source के लिए full-time कर्मचारी रखने की तुलना में सस्ता सपोर्ट मिल सकेगा
    • मुझे लगा curl का अस्तित्वहीन enterprise support contract बेवकूफ paperwork संभालने वालों को विनम्रता से दफा होने को कहने का तरीका है: https://daniel.haxx.se/blog/2022/01/24/logj4-security-inquir...
    • यह बेहद गैर-यूरोपीय तरीका है। यूरोप की कंपनियाँ आम तौर पर मई से अगस्त तक paid customers को भी नज़रअंदाज़ करती हैं
  • “बुरे लोग आराम नहीं करेंगे, लेकिन हम करेंगे” वाली बात अमानवीय समय में सुखद इंसानीपन देती है

    • अगर सच में कोई fix ज़रूरी हो, तो अच्छा लगता है कि उसका रास्ता मौजूद है
      कुछ ऐसा: “support contract साइन करो, तो हम इसे पहले पढ़ेंगे”
    • मुझे चिंता है कि बुरे लोग उस एक महीने में मिलने वाली vulnerabilities का खुलकर फायदा उठाने के लिए zero-day खोजने पर फोकस न करने लगें। फिर भी, यह बात संदेह से परे है कि उन्हें आराम की ज़रूरत है
  • जो लोग छुट्टी के दौरान सचमुच काम से पूरी तरह कट जाना चाहते हैं, उनके लिए बेहतर है कि वे खुद को काम करने में असमर्थ बना लें
    work device पीछे छोड़ दें, सभी accounts से log out कर दें, 2FA key को कागज़ पर backup करके हटा दें, और छुट्टी के दौरान partner से उसे वापस न दिलवाएँ। मैं तो एक बार ऐसे देश भी गया हूँ जहाँ remote work allowed नहीं था। पागलपन लगता है, लेकिन मामला इतना गंभीर था। यह एक पूर्व workaholic लिख रहा है

    • उत्तर अमेरिका छोड़कर यूरोप जाने की मेरी एक वजह यह भी थी कि वहाँ यह सामान्य माना जाता है। cultural difference बहुत बड़ा है
      जर्मनी में अगर आप छुट्टी पर हैं, तो बस आपसे संपर्क नहीं हो सकता। लौटने तक आपको दुनिया से गायब माना जाता है, आप email भी नहीं पढ़ते, और device भी office में छोड़ देते हैं। और अगर छुट्टी के दौरान बीमार पड़ जाएँ, तो छुट्टी के दिन वापस मिल जाते हैं, क्योंकि छुट्टी का मकसद आराम और recovery है
    • मेरा नज़रिया थोड़ा अलग है। छुट्टी में कभी-कभी email का जवाब देना ठीक है, लेकिन फिर कंपनी को भी काम के समय कभी-कभी निजी काम निपटाने पर आपत्ति नहीं होनी चाहिए; तभी यह fair deal है
      अगर कंपनी आने-जाने का समय सख्ती से गिने, हर 30 मिनट के निजी काम के लिए paid leave लेने को कहे, या काम लगातार हफ्ते के 40 घंटे से ऊपर जाने लगे, तो मैं भी “काम के बाहर” वाला काम बंद कर दूँगा। लेकिन अगर कंपनी reasonable है, तो मैं भी reasonable रह सकता हूँ
    • बैंक में काम करते समय अच्छी चीज़ों में से एक locked vacation थी। auditors इस बात की परवाह करते थे कि कर्मचारी लगातार दखल देने में सक्षम न रहें, और एक तय स्तर से ऊपर की permissions वाले कर्मचारियों को log in अधिकार निष्क्रिय करके लगातार N दिनों की छुट्टी लेना अनिवार्य था
      छिपे हुए bus factor को ढूँढने के लिए यह शानदार tool था
    • यह बहुत ज़्यादा अतिरिक्त मेहनत जैसा लगता है। अगर संभव हो, तो काम की चीज़ें सिर्फ work laptop/computer पर रखें, और उसे घर या office में छोड़ दें
      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 इंतज़ार कर सकती है

    • यही तो असली बात है। वे vulnerability reports लेने वाले ही नहीं हैं। वे छुट्टी पर जा रहे हैं
    • भले curl में खुद vulnerability न हो, लेकिन curl मनचाहा internet data डाउनलोड करने का tool है, इसलिए उसे शुरू से ही कड़े sandbox के अंदर होना चाहिए
      सिर्फ arbitrary data को shell तक डाउनलोड करना भी environment के बाकी हिस्सों में किसी vulnerability को गलती से trigger कर सकता है
  • इस फैसले की तारीफ किए बिना नहीं रह सकता। free open source project maintainers लगभग बिना किसी मुआवज़े के लगातार overloaded रहते हैं, और अब LLM की वजह से merge request संभालने का बोझ और भी विस्फोटक रूप से बढ़ गया है
    paid users को वे सपोर्ट देते रहेंगे, सिर्फ यही बात काफी है

  • मेंटेनर्स के प्रति सहानुभूति है, लेकिन आखिरकार यह फिर सामने आ गया कि हम लगभग मुफ़्त में काम करने वाले कुछ लोगों पर बिना किसी बैकअप के निर्भर हैं
    आम तौर पर संगठन ऐसी स्थिति से बचने के लिए छुट्टियां अलग-अलग समय पर तय करते हैं। ग्राहकों की मांग के कारण उन्हें ऐसा करना पड़ता है। यहां curl के ग्राहक तो सब हैं, लेकिन वास्तविकता में ऐसा भी नहीं है। यह एक अजीब और अस्वस्थ ग्रे ज़ोन लगता है जो किसी के लिए अच्छा नहीं है। यह बात चौंकाने वाली और दुखद भी है कि curl के पास एक महीने तक ऑन-कॉल रखने की वित्तीय क्षमता भी नहीं है

    • free/open source software की हैरतअंगेज़ बात यह है कि अगर मेंटेनर न हों, तो आपके पास पूरे अधिकार और पूरा source code होता है, इसलिए आप खुद उसे ठीक कर सकते हैं या किसी को पैसे देकर ठीक करवा सकते हैं
      यह रिश्ता तभी अस्वस्थ होता है जब कोई वारंटी नहीं को अवास्तविक अपेक्षाओं के साथ मिलाकर उस पर थोप दिया जाता है
    • वास्तव में है। लेख के अंत में कहा गया है कि अगर support contract है, तो वे जवाब देंगे और security issues भी संभालेंगे
      लेख का सार भी यही लगता है कि अगर support चाहिए, तो support contract खरीदिए
    • है
      “paid support contract वाले सभी लोगों को, बेशक, इस अवधि में भी पूरी और उचित सेवा मिलती है” ऐसा लिखा है
    • लेख में साफ़ लिखा है कि paid support contract होने पर हमेशा की तरह on-call बना रहेगा
    • मुझे लगता है कि इस स्थिति की चिंता करने के बावजूद, वह व्यक्ति ऑन-कॉल पर किसी को रखने का खर्च खुद नहीं देगा
  • vulnerabilities को लगातार ढूंढना, रिपोर्ट करना, उनका विश्लेषण करना, फिर patch करना, और नया version सभी users तक पहुंचाना—यह मौजूदा सिस्टम साफ़ तौर पर टिकाऊ नहीं है
    इंडस्ट्री को bugs और security issues से निपटने के लिए कोई वैकल्पिक सिस्टम ढूंढना होगा। अभी इंडस्ट्री अनजान बनने और अपनी नाकामी को rent-seeking के अवसर में बदलने को ज़्यादा पसंद करती है

    • बेहतर समाधान क्या है?
      और open source में जिस rent-seeking की बात की गई, उसके उदाहरण क्या हैं?
    • मुझे लगता है बात सही है, और समाधान है compartmentalization द्वारा security। देखें: https://qubes-os.org
  • सिर्फ़ एक वाक्य पढ़कर ही समझ गया कि डेवलपर स्वीडिश होगा

    • जो लोग परिचित नहीं हैं, उनके लिए: स्वीडन में summer vacation को बहुत गंभीरता से लिया जाता है। सालाना 25~30 दिन की छुट्टी + public holidays आम बात है, और अगर कर्मचारी के पास ऐसी छुट्टी है जिसे वह मांगकर ले सकता है, तो लगातार 4 हफ्तों की summer vacation की अनुमति देना व्यवहार में लगभग कानूनी आवश्यकता है
      संदर्भ: https://www.riksdagen.se/sv/dokument-och-lagar/dokument/sven...
    • नॉर्वे का होने के नाते, मुझे भी यही लगा। नॉर्वे तो मूल रूप से जुलाई में रुक जाता है
    • मैं भी बिल्कुल ऐसे ही हंसा। मेरी मुख्य नौकरी वाली कंपनी का भी स्वीडन ऑफिस है, और उनकी summer vacation तो दंतकथा जैसी है
      अमेरिका में भी ऑफिस है, और अमेरिकियों को जो cultural shock मिलता है, वह हर बार नया लगता है
    • मुझे भी तुरंत लगा कि वही आदमी होगा। ध्यान खींचने की भूख में उसके जैसा कोई मुश्किल से ही होगा
  • यूरोप में, जैसे जर्मनी में, 20~30 दिन का paid vacation और असीमित sick leave सामान्य है। sick leave 3 दिन से ज़्यादा हो तो डॉक्टर का note चाहिए
    अगर आप छुट्टी के दौरान बीमार पड़ते हैं, तो वे छुट्टी के दिन आपको वापस मिलते हैं। अगर छुट्टी के दौरान अचानक काम करना पड़ जाए, तो वह समय छुट्टी का समय नहीं माना जा सकता। आम तौर पर आपको बिना notice period के निकाला नहीं जा सकता, इसलिए नौकरी की स्थिरता ज़्यादा होती है, और नौकरी चली भी जाए तो unemployment support मिलता है, इसलिए करीब 6,000 डॉलर की emergency fund के साथ भी काफ़ी स्थिरता रहती है। क्या इससे अक्षम लोग निकाले नहीं जाते? ऐसा नहीं है। उन्हें अब भी निकाला जा सकता है, बस उसके बाद लगभग एक महीना और झेलना पड़ता है। यह कोई बहुत बड़ी कीमत नहीं है
    यह कैसे संभव है और सब्सिडी कौन देता है? बस सभी लोग अपनी आय का कुछ प्रतिशत देकर इस सिस्टम को बनाए रखते हैं। उन कुछ प्रतिशत, कुछ डॉलर की वजह से आपको भूख या बेघर होने की चिंता लगभग नहीं करनी पड़ती
    आप भी वोट कर सकते हैं, विरोध कर सकते हैं, और लोकतंत्र का इस्तेमाल करके सबकी ज़िंदगी को बदतर नहीं बल्कि बेहतर बना सकते हैं

 
GN⁺ 4 시간 전
Lobste.rs की राय
  • “बुरे लोग कभी आराम नहीं करते”, लेकिन फिर भी हमें आराम करना चाहिए
    उम्मीद है कि आप छुट्टियाँ अच्छी तरह बिताएँगे, और आप इसके पूरी तरह हकदार हैं। जो दूसरे लोग दबाव महसूस कर रहे हैं, वे भी छुट्टी लेने पर विचार करें तो अच्छा होगा

  • बुरे लोग vulnerability report भेजने वाले भी नहीं हैं, इसलिए इंतज़ार करते रहने से इस खतरे में कोई फर्क पड़ता नहीं दिखता
    व्यक्तिगत रूप से मुझे 4 हफ्ते की छुट्टी भी थोड़ी छोटी लगती है, लेकिन हो सकता है मैं कुछ ज़्यादा ही फ़्रांसीसी अंदाज़ में सोच रहा हूँ

    • लगता है Daniel स्वीडन के industrisemester कॉन्सेप्ट की ओर हल्का-सा इशारा कर रहे हैं
      आम तौर पर जुलाई में स्वीडन की मैन्युफैक्चरिंग फैक्ट्रियाँ ज़्यादातर कर्मचारियों को छुट्टी देती थीं, और उसी दौरान फैक्ट्री की जाँच, मेंटेनेंस और मरम्मत होती थी। आज भी बहुत से लोग midsummer के बाद एक महीने के भीतर अपनी सालाना छुट्टी रखना चाहते हैं, और क़ानूनी रूप से midsummer day 20~26 जून के बीच का शनिवार होता है
    • यह पूरी तरह की छुट्टी भी नहीं है। उन्होंने कहा है कि support contract से जुड़ा कोई issue हुआ तो वे फिर भी जवाब देंगे, तो असल में यह उससे भी छोटी छुट्टी है :-D
  • उम्मीद है वे छुट्टी का आनंद लें :)
    लेकिन हो सकता है उन्हें पता ही न चला हो कि वह पोस्ट जिसमें Mythos ने बड़े दबे स्वर में शेखी बघारी कि उसे सिर्फ एक bug मिला ने छत्ते में हाथ डाल दिया

    • शायद अमेरिकी सरकार ने latest Anthropic model तक पहुँच रोकने की असली वजह Daniel को छुट्टी दिलाना ही सोचा हो
    • वह उपमा शायद ठीक से फिट नहीं बैठती। Daniel तो पहले से ही कई सालों से भिनभिनाते झुंड से घिरे हुए थे, और सब लोग प्रतिष्ठित curl CVE पाने और अपनी साख बनाने में लगे हुए थे
  • यह देखना अच्छा लगता है। उम्मीद है इससे दूसरे open source maintainers को भी अपनी भलाई को प्राथमिकता देने की प्रेरणा मिलेगी

  • अच्छा लगा। काश दूसरे projects भी यही तरीका अपनाएँ