Freenginx: Nginx के मुख्य डेवलपर ने फोर्क की घोषणा की

मूल लेख ↗ Hacker News चर्चा ↗

एक मुख्य Nginx डेवलपर ने Freenginx नामक एक फोर्क बनाया है, क्योंकि सुरक्षा नीति को लेकर कॉर्पोरेट मालिक F5 के साथ टकराव हुआ, विशेष रूप से Nginx के experimental HTTP/3 कोड में एक vulnerability के लिए CVE जारी करने के निर्णय पर। टिप्पणीकार इस विभाजन को volunteer maintainers और critical open-source infrastructure पर corporate control के बीच गहरे तनाव का प्रतीक मानते हैं, और disclosure practices, trademarks, तथा project governance पर सवाल उठाते हैं। अब कई लोग विचार कर रहे हैं कि Nginx पर बने रहें, नए फोर्क पर जाएँ, या Caddy, HAProxy, या Angie जैसे विकल्पों पर स्विच करें।

फोर्क का कारण और शासन-विवाद

  • फोर्क (“Freenginx”) को गैर-तकनीकी कॉर्पोरेट प्रबंधन (F5) द्वारा nginx की लंबे समय से चली आ रही सुरक्षा नीति और डेवलपर प्राथमिकताओं को दरकिनार करने की प्रतिक्रिया के रूप में प्रस्तुत किया गया है।
  • तात्कालिक कारण यह दिखता है कि F5 ने HTTP/3/QUIC के प्रयोगात्मक कोड में एक बग के लिए सुरक्षा सलाह और CVE प्रकाशित किए, जबकि मुख्य मेंटेनर की इच्छा थी कि मौजूदा नीति के अनुसार इसे एक सामान्य बग माना जाए।
  • कुछ टिप्पणीकार इसे एक “rage-fork” मानते हैं; अन्य इसे एक ओपन-सोर्स प्रोजेक्ट पर नियंत्रण खोने और लंबे समय से बन रहे टकराव की वैध प्रतिक्रिया मानते हैं, न कि सिर्फ एक CVE पर आधारित।

CVE और सुरक्षा-नीति पर बहस

  • F5 के सुरक्षा कर्मचारी तर्क देते हैं कि उन्होंने CVE नियमों का पालन किया, कि प्रयोगात्मक लेकिन शिप किए गए फीचर्स दायरे में आते हैं, कि HTTP/3 पहले से प्रोडक्शन में उपयोग हो रहा है, और उपयोगकर्ताओं को सूचित किया जाना चाहिए।
  • विरोधी दृष्टिकोण: प्रयोगात्मक, डिफ़ॉल्ट-नहीं फीचर्स (या केवल DoS वाले बग्स) के लिए CVE देना शोर बढ़ाता है, CVE “गेमिफिकेशन” को बढ़ावा देता है, और downstreams पर कम-लाभ वाले “सुरक्षा” काम का बोझ डालता है।
  • व्यापक आलोचना यह भी है कि CVE की गिनती को KPI की तरह इस्तेमाल किया जाता है और सुरक्षा प्रक्रियाएँ अत्यधिक सख्त व राजनीतिक हो सकती हैं।

मौजूदा फोर्क, लाइसेंसिंग, और नामकरण

  • nginx का एक और फोर्क, Angie, पहले से मौजूद है; इसे एक लाभ-उन्मुख कंपनी चलाती है, इसमें CLA है, और “pro” संस्करण भी है; कुछ लोग इस मॉडल पर अविश्वास करते हैं, क्योंकि यह भविष्य में लाइसेंस बदलने की आशंका पैदा करता है।
  • Freenginx मूल 2-clause BSD लाइसेंस बनाए रखता है और GitHub के बाहर होस्ट किए गए Mercurial का उपयोग करता है।
  • कई लोग नोट करते हैं कि F5 के पास nginx ट्रेडमार्क है और वे डोमेन/नाम संबंधी टकराव की अपेक्षा करते हैं; rebrand करने के सुझाव भी बहुत हैं। अन्य लोग तर्क देते हैं कि सीमाओं के पार प्रवर्तन की संभावना कम है, लेकिन इससे .org डोमेन प्रभावित हो सकता है।

विकल्प और माइग्रेशन की चर्चा

  • बहुत से लोग HAProxy, Caddy, Traefik, lighttpd, या यहाँ तक कि Apache httpd की ओर जाने, या पहले ही जा चुके होने की चर्चा करते हैं, यह इस पर निर्भर करता है कि ज़रूरतें static file serving, simplicity, या advanced load balancing जैसी क्या हैं।
  • Caddy को automatic TLS और सरल config के लिए बार-बार सराहा जाता है, लेकिन इसका ecosystem nginx examples पर “doc-lock” से प्रभावित है।

तकनीकी और इकोसिस्टम संबंधी चिंताएँ

  • nginx को लेकर कई तकनीकी शिकायतें उठती हैं: reload पर HTTP/1.1 persistent connections का टूटना, historical request-smuggling issues (जिन्हें ठीक और hardened बताया गया है), HTTP/2 upstream support का अभाव, और कुछ “legacy” defaults।
  • अन्य लोग nginx की stability, performance, और “good enough” फीचर सेट का बचाव करते हैं; कई उपयोग मामलों के लिए, वर्षों पुराना nginx भी पर्याप्त होता।
  • कई टिप्पणीकार इस बात को लेकर चिंतित हैं कि critical infrastructure 1–2 core devs पर निर्भर है, लेकिन यह भी नोट करते हैं कि open source और forks आगे का रास्ता देते हैं, भले ही funding और sustainability की चुनौतियाँ हों।