- FFmpeg दुनिया भर में media processing का एक प्रमुख open source framework है, और VLC·Chrome·YouTube जैसी बड़ी सेवाओं में इस्तेमाल होने वाला एक अनिवार्य घटक है
- हाल ही में Google के AI-आधारित security scanner ने 1995 के एक game codec से जुड़ा मामूली bug खोजा, जिसके बाद यह बहस तेज हो गई कि बड़ी कंपनियां स्वैच्छिक developers पर जरूरत से ज्यादा बोझ डाल रही हैं
- FFmpeg का कहना है कि “यह project लगभग पूरी तरह volunteers द्वारा maintain किया जाता है,” इसलिए Google को सिर्फ vulnerability reports भेजने के बजाय patches देना या financial support भी करना चाहिए
- Google ने Project Zero की public policy और Patch Rewards program का हवाला देकर security में पारदर्शी योगदान पर जोर दिया, लेकिन FFmpeg community ने reward limits और व्यावहारिक support की कमी की ओर इशारा किया
- यह विवाद AI द्वारा बड़े पैमाने पर बनाए गए CVE और open source maintenance की sustainability के मुद्दे को सामने लाता है, और बड़ी tech कंपनियों की जिम्मेदारी पर बहस को आगे बढ़ाता है
FFmpeg और Google के बीच टकराव का सार
- FFmpeg एक open source multimedia framework है जो audio·video files के transcoding, playback, streaming को support करता है
- इसकी core libraries जैसे libavcodec, libavformat का उपयोग VLC, Kodi, Plex, Chrome, Firefox, YouTube आदि में होता है
- लेकिन दूसरे बड़े open source projects की तरह यह भी गंभीर वित्तीय कमी से जूझ रहा है
- Twitter पर FFmpeg, Google, Chainguard और security researchers के बीच security vulnerability disclosure के तरीके और जिम्मेदारी को लेकर बहस छिड़ गई
- चर्चा का मुख्य बिंदु यह था कि AI द्वारा बनाए गए बड़ी संख्या में vulnerability reports का वास्तविक मूल्य अक्सर कम होता है
विवाद की शुरुआत: Google AI द्वारा खोजा गया मामूली bug
- Google के AI agent ने FFmpeg में LucasArts Smush codec decoding से जुड़ा bug खोजा
- यह समस्या 1995 के game Rebel Assault 2 के केवल शुरुआती 10~20 frames को प्रभावित करने वाली मध्यम-स्तर की vulnerability थी
- FFmpeg developers ने इसे patch कर दिया, लेकिन ऐसी अप्रभावी reporting की आलोचना करते हुए इसे “CVE slop” कहा
- FFmpeg ने “FFmpeg aims to play every video file ever made” कहते हुए perfect compatibility को अपना लक्ष्य बताया, लेकिन यह भी कहा कि इसका अधिकांश code assembly language में लिखा गया है, इसलिए maintenance कठिन है
open source maintainers पर बढ़ता बोझ
- FFmpeg community ने आलोचना की कि Google जैसी बड़ी कंपनियां, जो FFmpeg का उपयोग करती हैं, unpaid volunteers पर vulnerabilities ठीक करने का बोझ डाल रही हैं
- उनका कहना है कि Google को vulnerability report भेजते समय patch या financial support भी साथ देना चाहिए
- इसी तरह के एक मामले में libxml2 के maintainer Nick Wellnhofer ने बार-बार आने वाली third-party security reports के कारण maintenance रोकने की घोषणा कर दी
- उनका कहना था कि “बिना भुगतान काम करने वाला volunteer हर हफ्ते कई घंटे security issues पर खर्च करे, यह sustainable नहीं है”
Google Project Zero की disclosure policy पर विवाद
- जुलाई 2025 में Google Project Zero(GPZ) ने ‘Reporting Transparency’ policy शुरू की
- vulnerability मिलने के एक हफ्ते के भीतर public disclosure, और उसके बाद 90 दिनों की fix deadline अपने-आप शुरू हो जाती है
- आलोचकों का कहना है कि patch तैयार न होने पर भी disclosure आगे बढ़ने से volunteer-driven projects पर जरूरत से ज्यादा दबाव पड़ता है
- FFmpeg ने सवाल उठाया, “क्या यह उचित है कि AI hobby code में security issues ढूंढे और volunteers से उन्हें ठीक करने की मांग करे?”
- Google का Patch Rewards Program मौजूद है, लेकिन FFmpeg का कहना है कि “महीने में 3 submissions जैसी सीमा के कारण यह व्यावहारिक मदद नहीं बन पाता”
अलग-अलग नजरिए और open source की sustainability
- Chainguard के Dan Lorenc ने Google की भूमिका का बचाव करते हुए कहा कि security vulnerabilities का disclosure भी digital public goods में योगदान है
- उनका तर्क था कि “Google open source support में सबसे सक्रिय कंपनियों में से एक है, और ऐसे विवाद sponsors को दूर भी कर सकते हैं”
- लेकिन FFmpeg का जोर है कि AI द्वारा बनाए गए बड़े पैमाने के CVE से निपटने के लिए उसके पास पर्याप्त लोग और फंड नहीं हैं
- security experts भी मानते हैं कि FFmpeg internet infrastructure का एक अहम हिस्सा है, इसलिए vulnerability disclosure जरूरी है
- लेख के अंत में कहा गया है कि “बड़ी कंपनियों के वास्तविक support के बिना core open source projects को बनाए रखना संभव नहीं,” और libxml2 के उदाहरण के साथ sustainable sponsorship structure की जरूरत पर जोर दिया गया है
15 टिप्पणियां
कहीं ऐसा तो नहीं कि यह WordPress Foundation और WP Engine के कॉर्पोरेट रिश्ते की तरह पूरी तरह टूट जाए?
यह https://daniel.haxx.se/blog/2024/…
का विस्तार लगता है।
ऊपर वाला लेख अगर ऐसे पूरी तरह गलत reports के बारे में था जिन्हें लोग bug bounty के लिए भेजते हैं, तो FFmpeg वाला मामला किसी बड़ी कंपनी की तरफ़ से भेजी गई valid लेकिन मामूली report का है।
क्या Google के बताने भर से उस पर ज़रूर कार्रवाई करनी चाहिए?
ऐसी स्थिति है जहाँ vulnerability खुद ही public हो जाती है, इसलिए लगता है कि इनके पास प्रतिक्रिया देने के अलावा कोई विकल्प नहीं होगा।
आह... ऐसा नज़रिया भी था। बताने के लिए धन्यवाद!
कमज़ोरी सार्वजनिक हो जाने पर उसी के ज़रिए हमला किया जा सकता है, यही बात है, डरावना।
असल में, चाहे यह सार्वजनिक हो या न हो, अगर तुम्हें इसकी इतनी ज़रूरत है तो खुद ही ठीक कर लो~ ऐसा भी कहा जा सकता है, लेकिन लगता है कि मेंटेनर ऐसे स्वभाव के लोग नहीं थे, तभी यह यहाँ तक विकसित हो पाया है।
आह.... लगता है आप सही कह रहे हैं.
मैंने शायद इसे अपनी ही नज़र से बहुत ज़्यादा सोचा था.
कहने के लिए धन्यवाद!
Hacker News राय
लेख में एक बात खास तौर पर प्रभावशाली लगी। Amazon के भीतर FFmpeg से जुड़ा फैसला रुकवाने के लिए Mark Atwood को अपने मैनेजरों से यह समझाना पड़ा था कि “वे कोई vendor नहीं हैं, NDA भी नहीं है, और हम उन पर कोई प्रभाव नहीं डाल सकते।”
मैं “सिर्फ समस्या मत लाओ, समाधान भी लाओ” वाली बात से सहमत हूँ, लेकिन अगर Google के पास bugs ढूँढने के लिए पैसा है, तो उसे उन्हें ठीक करने पर भी पैसा खर्च करना चाहिए
इससे private patches पर निर्भर नहीं रहना पड़ता, जिस project से पहले मदद मिली उसे कुछ लौटाया जा सकता है, और नैतिक रूप से भी यही सही है।
लेकिन व्यवहार में corporate compliance और process barriers की वजह से upstream करना मुश्किल हो जाता है
मैंने एक व्यंग्यात्मक लाइसेंस की कल्पना की, जिसमें S&P500 कंपनी का कोई कर्मचारी bug report भेजना चाहे तो उसे एक तय रकम donate करनी पड़े, और अगर वह एक निश्चित राशि से कम दे तो उसे किसी तय समय के भीतर जवाब की उम्मीद नहीं करनी चाहिए।
जब कंपनियाँ असुविधा होने पर software को private fork में चलाने या AGPL अपनाने में हिचकिचाती नहीं हैं, तो अब समय है कि वे सीधे इसकी कीमत चुकाएँ
एक open source maintainer के तौर पर, मैं इस भावना से सहमत हूँ कि बड़ी कंपनियाँ security issues public करके मानो मुफ्त श्रम थोपती हैं।
लेकिन व्यवहार में, रिपोर्ट कोई भी करे, security issue अंततः वही समस्या है जिसे मुझे ही ठीक करना होगा।
अगर कोई project security को प्राथमिकता नहीं देता तो वह भी ठीक है, लेकिन फिर उसे उससे जुड़े reputational risk भी स्वीकार करने होंगे
commercial कंपनियों पर जल्दी fix की मांग करना उचित है, लेकिन volunteer-based OSS पर वही मांग लागू करना यथार्थवादी नहीं है
कहा गया कि यह 1995 के एक game के सिर्फ शुरुआती 10–20 frames में होता है, इसलिए इसे ‘medium severity’ कहना मुझे बढ़ा-चढ़ाकर लगा।
यह maintainers का समय बर्बाद करने वाला मामला लगता है
अगर समस्या गंभीर है तो किसी के भी बताने से फायदा है, और अगर रिपोर्ट मामूली या गलत है तो उसे नज़रअंदाज़ किया जा सकता है।
आखिर कौन-से bugs ठीक करने हैं, इसका फैसला project को खुद करना चाहिए
मैं FFmpeg टीम के रुख का समर्थन करता हूँ। बहुत-सी कंपनियाँ FOSS का इस्तेमाल सिर्फ marketing image-washing के लिए करती हैं, असल योगदान के लिए नहीं।
जो लोग पहले शायद बस piracy करते, वे अब license की वजह से बिना अपराधबोध के इसका इस्तेमाल कर रहे हैं
उन codecs को भी test करना जिन्हें वह internally इस्तेमाल नहीं करता, स्पष्ट रूप से public good के लिए है।
हाँ, Google के पास FFmpeg को और funding देने की क्षमता है, लेकिन इस maintainer को सीधे fund देने से मैं सहमत नहीं हूँ
इसका उपयोग स्वतंत्र रूप से किया जा सकता है, लेकिन दुरुपयोग की गुंजाइश भी बहुत है।
GPL 3 को लेकर यह आलोचना हो सकती है कि वह बहुत आगे चला जाता है, लेकिन कम-से-कम उसका उद्देश्य शोषण रोकना था
एक तरफ वे लोग हैं जो मुफ्त में ऐसा software बनाते हैं जो पूरे युग को परिभाषित करता है, और दूसरी तरफ वे कंपनियाँ हैं जो उसका उपयोग करके सारी value extract कर लेती हैं।
पहले लोग प्रेम से चलते हैं, दूसरे लेन-देन से
बड़ी कंपनियों के लिए public vulnerability disclosure ज़रूरी है, लेकिन resource-constrained OSS के लिए इसका जोखिम अधिक हो सकता है
अगर Google जल्दी fixes चाहता है, तो patch भी साथ में submit करे, इससे सबका फायदा होगा
खासकर अगर वे LLM से खोजी जा सकने वाली vulnerabilities हैं, तो कभी-न-कभी उनके exploit होने की आशंका है।
disclosure की वजह से users खुद भी बचाव कर सकते हैं, और FFmpeg ने इसे ठीक करने का फैसला अपनी इच्छा से किया है।
security research अपने आप में open source के लिए उच्च-लागत वाला contribution है।
शोधकर्ताओं से यह कहना कि “तुम्हारा योगदान पर्याप्त नहीं है” उल्टा volunteers से मुफ्त श्रम मांगने जैसा है
FOSS की transparency वास्तव में security awareness बढ़ाने में मदद करती है
यह वास्तविक दुनिया के grey areas को स्वीकार नहीं करता
अगर “एक ईमेल से तीन product lines रुक सकती हैं,” तो सालाना 10–20 हज़ार डॉलर की funding भी insurance premium की तरह काफी सस्ती लगेगी
अगर Google और Amazon सिर्फ 50,000 डॉलर each भी दें, तो FFmpeg developers अधिक स्थिरता से काम कर सकते हैं,
और खासकर YouTube चलाने वाली Google के लिए 100,000–200,000 डॉलर देना मुश्किल नहीं होना चाहिए
Google के security lead ने FFmpeg में अपने contributions का सार बताते हुए यह Twitter thread साझा किया
एक trillion-dollar company के लिए यह कहना कि उसके पास लोग या पैसे कम हैं, विश्वसनीय नहीं लगता
मैं जानना चाहता हूँ कि Project Zero का उद्देश्य क्या है।
क्या सिर्फ vulnerabilities ढूँढने से आगे भी इसका कोई कारण है?
साथ ही security talent आकर्षित करने और reputation management में भी फायदा देता है।
लेकिन अगर इसके लिए संसाधन हैं, तो patch लिखने में भी निवेश होना चाहिए
संबंधित vulnerability Use After Free थी, और Google की AI ने इसे ढूँढा था।
लेकिन उसे ठीक करने में शायद 3 सेकंड भी न लगें।
इतना पैसा रखने वाली company का किसी volunteer project पर spam-जैसी bug reports फेंकना अप्रिय लगता है
उसे CVE मानने लायक भी नहीं, एक साधारण bug report ही काफी होती
memory leak से बचने के लिए ज्यादा जटिल fix चाहिए।
शायद इस codec का default disabled रहना ही सही दिशा है
खाने को दिया तो अब गठरी भी मांग रहे हैं
बग रिपोर्ट भी निश्चित रूप से एक अहम योगदान ही होगा...
यह कुछ ऐसा लगेगा जैसे कोई व्यक्ति अपनी मर्ज़ी से मोहल्ले की सफ़ाई कर रहा हो, और उस मोहल्ले में सबसे ज़्यादा ज़मीन का मालिक कोई रसूखदार आदमी उससे कह रहा हो, "वहाँ कोने में सिगरेट का टुकड़ा पड़ा है।"
मुझे भी लगता है कि यह तुलना सही बैठती है।
यह एक उपयुक्त उपमा है।
क्या यह वाकई कोई बड़ी बात है? पढ़ने पर पता चलता है कि यह एक मध्यम-स्तर की security vulnerability है, जो सिर्फ एक खास पुराने game के शुरुआती 10~20 frames में ही प्रभावी है। क्या आपको सच में लगता है कि यह FFmpeg के लिए कोई महत्वपूर्ण contribution है? open source community में सबसे महत्वपूर्ण contribution तो यह होना चाहिए कि स्थिर development संभव हो सके, उसके लिए sponsorship दी जाए—खासकर अगर वह कोई ऐसी कंपनी हो जो उसके नतीजों का अच्छी तरह उपयोग कर रही हो, तो मेरी नज़र में वही प्राथमिकता होनी चाहिए।
इसी तरह के लोगों की वजह से XZ में बैकडोर डाला गया था।
बग रिपोर्ट अपने आप में S-ग्रेड की है, लेकिन जब वे यह बात हर जगह फैलाते फिरते हैं कि Kennedy राष्ट्रपति के ज़माने में इस्तेमाल होने वाले वीडियो फ़ॉर्मैट की गंभीर vulnerability का तय समय के भीतर समाधान नहीं किया गया, तो समस्या वहीं से शुरू होती है।
वे खाने लायक चीज़ नहीं दे रहे, बल्कि ऐसी चीज़ दे रहे हैं जिसे हर हाल में खाना ही पड़े, और फिर पूछ रहे हैं कि तय समय के अंदर इसे खत्म क्यों नहीं किया।
ffmpeg के पास सीमित जनशक्ति है, तो क्या यह सही है कि Google AI की मदद से अब लगभग इस्तेमाल ही न होने वाले फ़ॉर्मैट्स पर दर्जनों bug reports उछाल दे और फिर उन सबको समय-सीमा के भीतर ठीक करने का दबाव डाले?