दशकों से, सॉफ्टवेयर के पुन: उपयोग पर चर्चा की गई है, जबकि यह वास्तव में था। आज स्थिति विपरीत है: डेवलपर्स सॉफ्टवेयर निर्भरता के रूप में हर दिन अन्य लोगों के कार्यक्रमों का पुन: उपयोग करते हैं, और समस्या स्वयं लगभग अस्पष्ट रहती है।

मेरे अपने अनुभव में Google की आंतरिक रिपॉजिटरी के साथ काम करने का एक दशक शामिल है , जहां निर्भरता को प्राथमिकता की अवधारणा के रूप में सेट किया गया है, साथ ही साथ गो प्रोग्रामिंग भाषा के लिए एक निर्भरता प्रणाली विकसित की जा रही है ।

निर्भरताएं गंभीर जोखिम उठाती हैं जिन्हें अक्सर अनदेखा किया जाता है। सॉफ्टवेयर के सबसे छोटे टुकड़ों के सरल पुन: उपयोग के लिए संक्रमण इतनी जल्दी हुआ है कि हमने अभी तक प्रभावी चयन और निर्भरता के उपयोग के लिए सर्वोत्तम प्रथाओं का विकास नहीं किया है। यहां तक ​​कि निर्णय लेने के लिए कि वे कब उचित हैं और कब नहीं। इस लेख का उद्देश्य जोखिमों का आकलन करना और इस क्षेत्र में समाधान की खोज को प्रोत्साहित करना है।

नशा क्या है?

आधुनिक विकास में, निर्भरता अतिरिक्त कोड है जिसे प्रोग्राम से कहा जाता है। निर्भरता जोड़ने से पहले से किए गए काम की पुनरावृत्ति से बचा जाता है: कोड की एक विशिष्ट इकाई को डिजाइन करना, लिखना, परीक्षण, डिबगिंग और समर्थन करना। हम कोड की इस इकाई को एक पैकेज कहते हैं , हालांकि कुछ प्रणालियों पर अन्य शर्तें, जैसे कि लाइब्रेरी या मॉड्यूल, का उपयोग पैकेज के बजाय किया जाता है।

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

एक निर्भरता प्रबंधक (कभी-कभी पैकेज प्रबंधक कहा जाता है) निर्भरता पैकेजों की डाउनलोड और स्थापना को स्वचालित करता है। क्योंकि निर्भरता प्रबंधक व्यक्तिगत पैकेजों को डाउनलोड और इंस्टॉल करना आसान बनाते हैं, निश्चित लागत कम करने से छोटे पैकेज प्रकाशित और पुन: उपयोग करने के लिए किफायती हो जाते हैं।

उदाहरण के लिए, एनपीएम नामक एक Node.js निर्भरता प्रबंधक 750,000 से अधिक पैकेज तक पहुंच प्रदान करता है। उनमें से एक, escape-string-regexp में एक एकल फ़ंक्शन होता है जो इनपुट डेटा से नियमित अभिव्यक्ति ऑपरेटरों से बचता है। सभी कार्यान्वयन:

 var matchOperatorsRe = /[|\\{}()[\]^$+*?.]/g; module.exports = function (str) { if (typeof str !== 'string') { throw new TypeError('Expected a string'); } return str.replace(matchOperatorsRe, '\\$&'); }; 

इससे पहले कि निर्भरता प्रबंधकों ने दिखाई, आठ-लाइन लाइब्रेरी को प्रकाशित करने की कल्पना करना असंभव था: बहुत अधिक उपरि और बहुत कम लाभ। लेकिन एनपीएम ने ओवरहेड को लगभग शून्य कर दिया, जिसके परिणामस्वरूप लगभग तुच्छ कार्यक्षमता को पैक और पुन: उपयोग किया जा सकता है। जनवरी 2019 के अंत में, escape-string-regexp निर्भरता लगभग एक हजार अन्य एनपीएम पैकेजों में बनाया गया था, उन सभी पैकेजों का उल्लेख नहीं करने के लिए जो डेवलपर्स अपने स्वयं के उपयोग के लिए लिखते हैं और सार्वजनिक डोमेन में प्रकाशित नहीं करते हैं।

अब निर्भरता प्रबंधक लगभग हर प्रोग्रामिंग भाषा के लिए दिखाई दिए हैं। मावेन सेंट्रल (जावा), नुगेट (.NET), पैकगिस्ट (PHP), PyPI (अजगर) और RubyGems (रूबी) - इनमें से प्रत्येक में 100,000 से अधिक पैकेज हैं। छोटे पैकेजों के ऐसे व्यापक पुन: उपयोग का आगमन पिछले दो दशकों में सॉफ्टवेयर विकास के सबसे बड़े परिवर्तनों में से एक है। और अगर हम अधिक सावधान नहीं हैं, तो इससे गंभीर समस्याएं पैदा होंगी।

क्या गलत हो सकता है?

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

हम सहमत हैं, क्योंकि यह आसान है, क्योंकि सब कुछ काम करने लगता है, क्योंकि हर कोई इसे भी करता है, और सबसे महत्वपूर्ण बात, क्योंकि यह एक सदियों पुरानी स्थापित प्रथा की स्वाभाविक निरंतरता है। लेकिन एक महत्वपूर्ण अंतर है जिसे हम नजरअंदाज कर देते हैं।

दशकों पहले, अधिकांश डेवलपर्स ने उन कार्यक्रमों को लिखने के लिए भी भरोसा किया जिन पर वे निर्भर थे, जैसे कि ऑपरेटिंग सिस्टम और कंपाइलर। यह सॉफ्टवेयर प्रसिद्ध स्रोतों से खरीदा गया था, अक्सर कुछ प्रकार के समर्थन समझौते के साथ। अभी भी त्रुटियों या एकमुश्त wrecking के लिए जगह है । लेकिन हम कम से कम जानते थे कि हम किसके साथ व्यवहार कर रहे थे और एक नियम के रूप में, प्रभाव के वाणिज्यिक या कानूनी उपायों का उपयोग कर सकते थे।

ओपन सोर्स सॉफ्टवेयर की घटना, जिसे इंटरनेट पर नि: शुल्क वितरित किया जाता है, ने बड़े पैमाने पर सॉफ्टवेयर खरीदने की पुरानी प्रथा को समाप्त कर दिया है। जब पुन: उपयोग अभी भी मुश्किल था, कुछ परियोजनाओं ने इस तरह की निर्भरताएं पेश कीं। हालांकि उनके लाइसेंसों ने आमतौर पर किसी विशेष उद्देश्य के लिए "वाणिज्यिक मूल्य और उपयुक्तता की गारंटी" को माफ कर दिया, लेकिन परियोजनाओं ने एक अच्छी प्रतिष्ठा बनाई। अपने निर्णय लेते समय उपयोगकर्ताओं ने बड़े पैमाने पर इस प्रतिष्ठा को ध्यान में रखा है। वाणिज्यिक और कानूनी हस्तक्षेपों के बजाय, प्रतिष्ठित समर्थन आया। उस युग के कई सामान्य पैकेज अभी भी एक अच्छी प्रतिष्ठा का आनंद लेते हैं: उदाहरण के लिए, BLAS (1979 में प्रकाशित), नेटलिब (1987), libjpeg (1991), LAPACK (1992), HP STL (1994), और zlib (1995)।

बैच प्रबंधकों ने कोड पुन: उपयोग मॉडल को अत्यधिक सरलता में कम कर दिया है: अब डेवलपर्स दर्जनों लाइनों में व्यक्तिगत कार्यों के लिए सटीक के साथ कोड साझा कर सकते हैं। यह एक महान तकनीकी उपलब्धि है। अनगिनत पैकेज उपलब्ध हैं, और एक परियोजना में उनमें से एक बड़ी संख्या शामिल हो सकती है, लेकिन वाणिज्यिक, कानूनी या प्रतिष्ठित कोड ट्रस्ट तंत्र अतीत की बात है। हम अधिक कोड पर भरोसा करते हैं, हालांकि विश्वास के कम कारण हैं।

एक बुरी लत बनाने की लागत को इसकी संभावना (जोखिम) द्वारा गुणा किए गए प्रत्येक बुरे परिणाम की कीमत की श्रृंखला में सभी संभावित बुरे परिणामों के योग के रूप में देखा जा सकता है।


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

अपेक्षित मूल्य के बावजूद, निर्भरता जोड़ने के जोखिमों का आकलन करने और कम करने के लिए कुछ दृष्टिकोण हैं। यह संभावना है कि पैकेज प्रबंधकों को इन जोखिमों को कम करने के लिए अनुकूलित किया जाना चाहिए, जबकि अभी तक उन्होंने डाउनलोड करने और स्थापित करने की लागत को कम करने पर ध्यान केंद्रित किया है।

निर्भरता की जाँच

आप एक ऐसे डेवलपर को काम पर नहीं रखेंगे, जिसके बारे में आपने कभी नहीं सुना हो और न ही उसके बारे में कुछ जानते हों। सबसे पहले, आप उसके बारे में कुछ सीखेंगे: लिंक की जाँच करें, एक साक्षात्कार का संचालन करें, और इसी तरह। इंटरनेट पर आपको मिलने वाले पैकेज के आधार पर, इस पैकेज के बारे में थोड़ा सीखना भी बुद्धिमानी है।

एक बुनियादी जांच इस कोड का उपयोग करने की कोशिश करते समय समस्याओं की संभावना का एक विचार दे सकती है। यदि निरीक्षण के दौरान छोटी समस्याएं पाई जाती हैं, तो आप उन्हें खत्म करने के उपाय कर सकते हैं। यदि चेक गंभीर समस्याओं को प्रकट करता है, तो पैकेज का उपयोग न करना बेहतर हो सकता है: आपको अधिक उपयुक्त मिल सकता है, या शायद आपको इसे स्वयं विकसित करने की आवश्यकता है। याद रखें कि ओपन सोर्स पैकेज लेखकों द्वारा इस उम्मीद में प्रकाशित किए जाते हैं कि वे उपयोगी होंगे, लेकिन प्रयोज्य या समर्थन की गारंटी के बिना। उत्पादन विफलता की स्थिति में, इसे डीबग करना आपके ऊपर है। जैसा कि पहले GNU जनरल पब्लिक लाइसेंस ने चेतावनी दी थी, "कार्यक्रम की गुणवत्ता और प्रदर्शन से जुड़े सभी जोखिम आपके साथ हैं। यदि कार्यक्रम दोषपूर्ण हो जाता है, तो आप सभी आवश्यक रखरखाव, मरम्मत या सुधार की लागत वहन करते हैं। "

इसके बाद, हम पैकेज की जाँच करने और उस पर निर्भर होने का निर्णय लेने के लिए कुछ विचारों को रेखांकित करते हैं।

डिज़ाइन

क्या पैकेज प्रलेखन स्पष्ट है? क्या एपीआई में एक स्पष्ट डिजाइन है? यदि लेखक किसी व्यक्ति को एपीआई और डिजाइन की अच्छी तरह से व्याख्या कर सकते हैं, तो यह संभावना बढ़ जाती है कि वे स्रोत कोड में कंप्यूटर के कार्यान्वयन को अच्छी तरह से समझाते हैं। एक स्पष्ट, अच्छी तरह से डिज़ाइन किया गया एपीआई के लिए कोड लिखना सरल, तेज़ और संभवतः कम त्रुटि वाला है। क्या लेखकों ने दस्तावेज किया है कि वे ग्राहक कोड से क्या उम्मीद करते हैं कि वे भविष्य के अपडेट के साथ संगत होंगे? (उदाहरणों में C ++ और गो संगतता दस्तावेज़ शामिल हैं)।

कोड की गुणवत्ता

क्या कोड अच्छी तरह से लिखा गया है? कुछ स्निपेट पढ़ें। क्या लेखक सावधान, कर्तव्यनिष्ठ और सुसंगत प्रतीत होते हैं? क्या यह उस कोड की तरह दिखता है जिसे आप डीबग करना चाहते हैं? आपको ऐसा करना पड़ सकता है।

कोड गुणवत्ता को सत्यापित करने के लिए अपने स्वयं के व्यवस्थित तरीके विकसित करें। कुछ सरल, जैसे कि महत्वपूर्ण संकलक चेतावनियों के साथ C या C ++ में संकलित करना (उदाहरण के लिए -Wall ), इस बात का अंदाजा लगा सकता है कि डेवलपर्स ने विभिन्न अपरिभाषित व्यवहारों से बचने के लिए कितनी गंभीरता से काम किया है। हाल की भाषाएं, जैसे कि गो, जंग और स्विफ्ट, कोड को निरूपित करने के लिए unsafe कीवर्ड का उपयोग करते हैं जो कि टाइप सिस्टम का उल्लंघन करता है; देखो कितना असुरक्षित कोड है। अधिक उन्नत सिमेंटिक टूल जैसे कि इनफेर या स्पॉटबग्स भी उपयोगी हैं। लिंटर्स कम उपयोगी होते हैं: आपको कोष्ठक शैली जैसे विषयों पर मानक युक्तियों को अनदेखा करना चाहिए और सिमेंटिक मुद्दों पर ध्यान केंद्रित करना चाहिए।

उन विकास विधियों के बारे में मत भूलिए जिनसे आप परिचित नहीं हो सकते हैं। उदाहरण के लिए, SQLite पुस्तकालय 200,000 कोड के साथ एक फ़ाइल के रूप में और 11,000 लाइनों के एक हेडर के रूप में आता है - कई फ़ाइलों को मर्ज करने के परिणामस्वरूप। इन फ़ाइलों का आकार तुरंत लाल झंडा उठाता है, लेकिन अधिक गहन शोध से विकास के लिए वास्तविक स्रोत कोड होगा: एक पारंपरिक फ़ाइल ट्री जिसमें सौ से अधिक स्रोत सी फाइलें, परीक्षण और समर्थन स्क्रिप्ट हैं। यह पता चला है कि एकल-फ़ाइल वितरण मूल स्रोतों से स्वचालित रूप से बनाया गया है: यह अंत उपयोगकर्ताओं के लिए आसान है, विशेष रूप से जिनके पास आश्रित प्रबंधक नहीं हैं। (संकलित कोड भी तेजी से काम करता है क्योंकि कंपाइलर अधिक अनुकूलन विकल्प देखता है)।

परीक्षण

क्या कोड में कोई परीक्षण हैं? क्या आप उन्हें नियंत्रित कर सकते हैं? क्या वे पास हो गए? परीक्षण स्थापित करते हैं कि कोड की मुख्य कार्यक्षमता सही है, और संकेत दें कि डेवलपर इसे रखने की गंभीरता से कोशिश कर रहा है। उदाहरण के लिए, SQLite विकास के पेड़ में 30,000 से अधिक व्यक्तिगत परीक्षण मामलों के साथ एक अविश्वसनीय रूप से विस्तृत परीक्षण सूट होता है। डेवलपर्स के लिए परीक्षण रणनीति की व्याख्या करने वाला दस्तावेज है । दूसरी ओर, अगर कुछ या कोई परीक्षण नहीं हैं, या यदि परीक्षण विफल हो जाते हैं, तो यह एक गंभीर लाल झंडा है: पैकेज में भविष्य में होने वाले बदलावों से उन प्रतिगमनों का नेतृत्व करने की संभावना है जिन्हें आसानी से पता लगाया जा सकता है। यदि आप अपने कोड (दाएं?) में परीक्षण पर जोर देते हैं, तो आपको उस कोड के लिए परीक्षण प्रदान करना होगा जिसे आप दूसरों को देते हैं।

मान लें कि परीक्षण मौजूद हैं, चलाएं और पास करें, आप कोड कवरेज का विश्लेषण करने, दौड़ की स्थिति का पता लगाने , स्मृति आवंटन की जांच करने और स्मृति लीक का पता लगाने के लिए उपकरण चलाकर अतिरिक्त जानकारी एकत्र कर सकते हैं।

डिबगिंग

इस पैकेज के लिए बग ट्रैकर खोजें। क्या कई खुले त्रुटि संदेश हैं? वे कब से खुले हैं? कितने कीड़े तय हो गए हैं? क्या हाल ही में कोई कीड़े तय किए गए हैं? यदि वास्तविक बग के बारे में कई खुले प्रश्न हैं, खासकर लंबे समय तक बंद नहीं हैं, तो यह एक बुरा संकेत है। दूसरी ओर, यदि त्रुटियां दुर्लभ हैं और जल्दी से ठीक हो जाती हैं, तो यह बहुत अच्छा है।

समर्थन

कमिट्स के इतिहास को देखें। कोड को कितनी देर तक सक्रिय रूप से बनाए रखा गया है? क्या यह अब सक्रिय रूप से समर्थित है? लंबे समय तक सक्रिय रूप से समर्थित पैकेजों का समर्थन जारी रखने की संभावना है। कितने लोग पैकेज पर काम कर रहे हैं? कई पैकेज व्यक्तिगत परियोजनाएं हैं जो डेवलपर्स अपने खाली समय में मनोरंजन के लिए बनाते हैं। अन्य भुगतानकर्ताओं के समूह के लिए हजारों घंटे के काम का परिणाम हैं। सामान्य तौर पर, दूसरे प्रकार के पैकेज आमतौर पर त्रुटियों को अधिक तेज़ी से ठीक करते हैं, लगातार नए कार्यों को पेश करते हैं, और सामान्य तौर पर वे बेहतर समर्थित होते हैं।

दूसरी ओर, कुछ कोड वास्तव में "सही" है। उदाहरण के लिए, एनपीएम से escape-string-regexp को फिर से बदलने की आवश्यकता नहीं हो सकती है।

के उपयोग

इस कोड पर कितने पैकेज निर्भर करते हैं? पैकेज प्रबंधक अक्सर ऐसे आंकड़े देते हैं, या आप इंटरनेट पर देख सकते हैं कि अन्य डेवलपर्स कितनी बार इस पैकेज का उल्लेख करते हैं। बड़ी संख्या में उपयोगकर्ताओं का मतलब कम से कम इस तथ्य से है कि कई कोड बहुत अच्छी तरह से काम करते हैं, और इसमें त्रुटियों को अधिक तेज़ी से देखा जाएगा। व्यापक उपयोग भी निरंतर सेवा की एक आंशिक गारंटी है: यदि एक व्यापक रूप से इस्तेमाल किया गया पैकेज अपने अनुचर को खो देता है, तो यह बहुत संभावना है कि एक इच्छुक उपयोगकर्ता अपनी भूमिका निभाएगा।

उदाहरण के लिए, PCRE, Boost या JUnit जैसी लाइब्रेरी अविश्वसनीय रूप से व्यापक रूप से उपयोग की जाती हैं। इससे यह अधिक संभावना है - हालांकि यह निश्चित रूप से गारंटी नहीं देता है - कि जिन त्रुटियों का आपको सामना करना पड़ा है, वे पहले से ही तय हैं क्योंकि दूसरों ने आपके सामने उनका सामना किया।

सुरक्षा

क्या यह पैकेज असुरक्षित इनपुट के साथ काम करेगा? यदि हां, तो यह दुर्भावनापूर्ण डेटा के लिए कितना प्रतिरोधी है? क्या उसके पास बग्स हैं जिनका उल्लेख राष्ट्रीय भेद्यता डेटाबेस (एनवीडी) में किया गया है ?

उदाहरण के लिए, जब 2006 में जेफ डीन और मैंने Google कोड सर्च (सार्वजनिक कोड आधारों के लिए grep ) पर काम करना शुरू किया, तो लोकप्रिय नियमित अभिव्यक्ति लाइब्रेरी पीसीआरई स्पष्ट पसंद प्रतीत हुई। हालाँकि, Google सुरक्षा टीम के साथ बातचीत में, हमें पता चला कि PCRE में समस्याओं का एक लंबा इतिहास है, जैसे कि बफर ओवरफ्लो, विशेष रूप से पार्सर में। हम खुद एनवीडी में पीसीआरई की तलाश में इस बारे में आश्वस्त थे। इस खोज ने हमें तुरंत PCRE को छोड़ने के लिए प्रेरित नहीं किया, बल्कि हमें परीक्षण और अलगाव के बारे में अधिक सावधानी से सोचने के लिए प्रेरित किया।

लाइसेंस

क्या कोड सही तरीके से लाइसेंस प्राप्त है? क्या उसके पास लाइसेंस भी है? क्या लाइसेंस आपकी परियोजना या कंपनी के लिए स्वीकार्य है? GitHub परियोजनाओं के एक अद्भुत हिस्से के पास स्पष्ट लाइसेंस नहीं है। आपकी परियोजना या कंपनी निर्भरता लाइसेंस पर अतिरिक्त प्रतिबंध लगा सकती है। उदाहरण के लिए, Google AGPL (बहुत तंग) और लाइसेंस WTFPL (बहुत अस्पष्ट) जैसे लाइसेंस के तहत कोड के उपयोग पर प्रतिबंध लगाता है ।

पर निर्भर करता है

क्या इस पैकेज की अपनी निर्भरता है? अप्रत्यक्ष निर्भरता में कमी प्रत्यक्ष निर्भरता में नुकसान के रूप में हानिकारक हैं। पैकेज प्रबंधक किसी दिए गए पैकेज की सभी परिवर्तनशील निर्भरता को सूचीबद्ध कर सकते हैं, और उनमें से प्रत्येक को आदर्श रूप से इस खंड में वर्णित के रूप में जांचना चाहिए। कई निर्भरता वाले पैकेज में बहुत काम की आवश्यकता होगी।

कई डेवलपर्स ने कभी भी अपने कोड की परिवर्तनशील निर्भरता की पूरी सूची को नहीं देखा है और यह नहीं जानते कि वे किस पर निर्भर करते हैं। उदाहरण के लिए, मार्च 2016 में, एनपीएम उपयोगकर्ता समुदाय ने पाया कि कई लोकप्रिय परियोजनाएं - जिसमें बाबेल, एम्बर और रिएक्ट शामिल हैं - अप्रत्यक्ष रूप से एक छोटे पैकेज पर निर्भर करते हैं जिसे 8-लाइन फ़ंक्शन के left-pad कहा जाता है। उन्हें यह पता चला जब left-pad के लेखक ने एनपीएम से पैकेज हटा दिया, अनजाने में Node.js उपयोगकर्ताओं की अधिकांश विधानसभाओं को तोड़ दिया । और इस संबंध में left-pad शायद ही असाधारण है। उदाहरण के लिए, एनपीएम में 750,000 पैकेट में से 30% निर्भर करते हैं - कम से कम अप्रत्यक्ष रूप से - escape-string-regexp । वितरित प्रणालियों के लेस्ली लामपोर्ट के अवलोकन को अपनाने से, पैकेज प्रबंधक आसानी से एक ऐसी स्थिति बनाता है जहां एक पैकेज विफलता, जिसके अस्तित्व को आप भी नहीं जानते थे, अपना कोड अनुपयोगी बना सकते हैं।

लत की जाँच

सत्यापन प्रक्रिया में अपने स्वयं के पैकेज परीक्षण चलाना शामिल होना चाहिए। यदि पैकेज ने परीक्षा पास कर ली है और आप अपनी परियोजना को उस पर निर्भर बनाने का निर्णय लेते हैं, तो अगला कदम आपके आवेदन की कार्यक्षमता पर विशेष रूप से केंद्रित नए परीक्षण लिखना चाहिए। ये परीक्षण अक्सर छोटे स्टैंड-अलोन कार्यक्रमों के रूप में शुरू होते हैं ताकि आप यह सुनिश्चित कर सकें कि आप पैकेज एपीआई को समझ सकते हैं और यह वही है जो आप सोचते हैं (यदि आप समझ नहीं सकते हैं या यह आपकी ज़रूरत नहीं है, तो तुरंत रोकें!)। फिर इन कार्यक्रमों को स्वचालित परीक्षणों में बदलने का अतिरिक्त प्रयास है जो पैकेज के नए संस्करणों के साथ चलेंगे। यदि आपको कोई गलती मिलती है और आपके पास एक संभावित फ़िक्स है, तो आप किसी विशिष्ट प्रोजेक्ट के लिए इन परीक्षणों को आसानी से पुनः आरंभ कर सकते हैं और सुनिश्चित कर सकते हैं कि फ़िक्स कुछ और नहीं हुआ था।

आधारभूत समीक्षा के दौरान पहचाने गए समस्या क्षेत्रों पर विशेष ध्यान दिया जाना चाहिए। पिछले अनुभव से, कोड खोज के लिए, हम जानते थे कि PCRE को कभी-कभी कुछ नियमित अभिव्यक्तियों को निष्पादित करने में लंबा समय लगता है। हमारी प्रारंभिक योजना "सरल" और "जटिल" नियमित अभिव्यक्तियों के लिए अलग-अलग थ्रेड पूल बनाने की थी। पहले परीक्षणों में से एक एक बेंचमार्क था pcregrep कई अन्य grep कार्यान्वयन के साथ pcregrep की तुलना की। जब हमने पाया कि pcregrep एक मूल परीक्षण मामले के लिए सबसे तेज़ grep से 70 गुना धीमा था, तो हमने PCRE का उपयोग करने के लिए अपनी योजना पर पुनर्विचार करना शुरू कर दिया। इस तथ्य के बावजूद कि हमने अंततः पीसीआरई को पूरी तरह से छोड़ दिया, यह परीक्षण आज हमारे कोड बेस में बना हुआ है।

निर्भरता अमूर्तता

पैकेज निर्भरता एक ऐसा समाधान है जिसे आप भविष्य में चुन सकते हैं। शायद अपडेट पैकेज को एक नई दिशा में ले जाएंगे। गंभीर सुरक्षा मुद्दे मिल सकते हैं। शायद सबसे अच्छा विकल्प दिखाई देगा। इन सभी कारणों से, यह परियोजना के प्रवासन को एक नई निर्भरता को सरल बनाने के प्रयास के लायक है।

यदि प्रोजेक्ट स्रोत कोड में कई स्थानों से पैकेज कहा जाता है, तो आपको एक नई निर्भरता पर स्विच करने के लिए इन सभी विभिन्न स्थानों पर बदलाव करने की आवश्यकता होगी। इससे भी बदतर, अगर पैकेज को आपकी अपनी परियोजना के एपीआई में प्रस्तुत किया जाता है, तो एक नई निर्भरता की ओर पलायन करने से आपको अपने एपीआई को कॉल करने वाले सभी कोड में बदलाव करने की आवश्यकता होगी, और यह पहले से ही आपके नियंत्रण से बाहर हो सकता है। इस तरह की लागतों से बचने के लिए, यह एक पतली आवरण के साथ अपने स्वयं के इंटरफ़ेस को परिभाषित करने के लिए समझ में आता है जो निर्भरता का उपयोग करके इस इंटरफ़ेस को लागू करता है। कृपया ध्यान दें कि रैपर में केवल वही शामिल होना चाहिए जो परियोजना को निर्भरता से चाहिए, और न कि सब कुछ जो निर्भरता प्रदान करता है। आदर्श रूप से, यह आपको बाद में एक और, समान रूप से उपयुक्त निर्भरता को बदलने की अनुमति देता है, केवल आवरण को बदलकर।नए इंटरफ़ेस का उपयोग करने के लिए प्रत्येक प्रोजेक्ट के लिए परीक्षणों का प्रवासन इंटरफ़ेस और आवरण के कार्यान्वयन की जांच करता है, और निर्भरता के लिए किसी भी संभावित प्रतिस्थापन के परीक्षण को भी सरल करता है।

कोड खोज के लिए, हमने एक सार वर्ग विकसित किया है जो Regexpकिसी भी नियमित अभिव्यक्ति इंजन से आवश्यक कोड खोज इंटरफ़ेस को परिभाषित करता है। तब उन्होंने PCRE के चारों ओर एक पतला आवरण लिखा जो इस इंटरफ़ेस को लागू करता है। इस पद्धति ने वैकल्पिक पुस्तकालयों का परीक्षण करना आसान बना दिया और आंतरिक पीसीआरई घटकों के ज्ञान के आकस्मिक परिचय को स्रोत के बाकी पेड़ में रोक दिया। यह बदले में, यह सुनिश्चित करता है कि यदि आवश्यक हो तो दूसरे निर्भरता पर स्विच करना आसान होगा।

निर्भरता अलगाव

इसमें त्रुटियों के कारण होने वाले संभावित नुकसान को सीमित करने के लिए रन टाइम पर निर्भरता को अलग करना भी उपयुक्त हो सकता है। उदाहरण के लिए, Google Chrome उपयोगकर्ताओं को ब्राउज़र - एक्सटेंशन कोड पर निर्भरता जोड़ने की अनुमति देता है। जब क्रोम ने पहली बार 2008 में लॉन्च किया था, तो ऑपरेटिंग सिस्टम की एक अलग प्रक्रिया में चल रहे सैंडबॉक्स में प्रत्येक एक्सटेंशन को अलग करने के लिए एक महत्वपूर्ण फ़ंक्शन (अब सभी ब्राउज़रों पर मानक) पेश किया । खराब तरीके से लिखे गए विस्तार में संभावित शोषण में ब्राउज़र की सभी मेमोरी तक स्वचालित पहुँच नहीं थीऔर अनुचित सिस्टम कॉल नहीं कर सका। कोड खोज के लिए, जब तक हमने PCRE को पूरी तरह से नहीं गिराया, तब तक कम से कम एक समान सैंडबॉक्स में PCRE पार्सर को अलग करने की योजना थी। आज, एक और विकल्प हल्का हाइपरवाइज़र-आधारित सैंडबॉक्स होगा, जैसे कि जीवीज़र । निर्भरता अलगाव इस कोड को निष्पादित करने के जुड़े जोखिमों को कम करता है।

यहां तक ​​कि इन उदाहरणों और अन्य तैयार विकल्पों के साथ, रनटाइम पर संदिग्ध कोड को अलग करना अभी भी बहुत जटिल है और शायद ही कभी प्रदर्शन किया जाता है। सच्चा अलगाव को बिना कोड के दुर्घटनाग्रस्त होने के लिए पूरी तरह से मेमोरी-सुरक्षित भाषा की आवश्यकता होगी। ये न केवल पूरी तरह से असुरक्षित भाषाओं में, जैसे कि C और C ++, बल्कि उन भाषाओं में भी जटिल हैं जो असुरक्षित परिचालन को प्रतिबंधित करती हैं, जैसे कि जावा जब JNI चालू होता है, या जब आप अपने असुरक्षित कार्यों को सक्षम करते हैं, जैसे Go, Rust और Swift। यहां तक ​​कि जावास्क्रिप्ट जैसी स्मृति-सुरक्षित भाषा में, कोड की अक्सर जरूरत से ज्यादा पहुंच होती है। नवंबर 2018 में, यह पता चला कि npm पैकेज के नवीनतम संस्करण event-stream(जावास्क्रिप्ट घटनाओं के लिए एक कार्यात्मक स्ट्रीमिंग एपीआई) में भ्रामक कोड शामिल हैंढाई महीने पहले जोड़ा गया। कोड ने कोपाए मोबाइल एप्लिकेशन के उपयोगकर्ताओं से बिटकॉइन वॉलेट एकत्र किए, सिस्टम संसाधनों तक पहुंच प्राप्त की, जो कि ईवेंट फ़्लो के प्रसंस्करण से पूरी तरह असंबंधित है। इस प्रकार की समस्याओं से बचाव के कई संभावित तरीकों में से एक बेहतर निर्भरता अलगाव होगा।

व्यसन का त्याग

यदि नशा बहुत जोखिम भरा लगता है और आप इसे अलग नहीं कर सकते हैं, तो सबसे अच्छा विकल्प इसे पूरी तरह से छोड़ देना या कम से कम सबसे समस्याग्रस्त भागों को बाहर करना हो सकता है।

उदाहरण के लिए, जब हमने PCRE के जोखिमों को बेहतर ढंग से समझा, तो Google कोड खोज के लिए हमारी योजना "PCRE का उपयोग करके सीधे PCRE लाइब्रेरी का उपयोग करने से बदल गई", "PCRE का उपयोग करें, लेकिन सैंडर को सैंडबॉक्स में रखें", फिर "एक नया नियमित अभिव्यक्ति पार्सर लिखें, लेकिन PCRE इंजन को सहेजें", फिर "एक नया पार्सर लिखें और इसे दूसरे, अधिक कुशल ओपन सोर्स इंजन से कनेक्ट करें।" बाद में, जेफ डीन और मैंने इंजन को फिर से लिखा, इसलिए कोई निर्भरता नहीं बची थी, और हमने परिणाम की खोज की: RE2 ।

यदि आपको निर्भरता के केवल एक छोटे से हिस्से की आवश्यकता है, तो सबसे आसान तरीका यह है कि आपको इसकी आवश्यकता की एक प्रतिलिपि बनाना है (निश्चित रूप से, प्रासंगिक कॉपीराइट और अन्य कानूनी नोटिसों को ध्यान में रखते हुए)। आप त्रुटि सुधार, रखरखाव आदि की जिम्मेदारी लेते हैं, लेकिन आप बड़े जोखिमों से पूरी तरह अलग-थलग हैं। गो डेवलपर समुदाय में एक कहावत है: "थोड़ी सी नकल निर्भरता की तुलना में बेहतर है।"

निर्भरता अद्यतन

एक लंबे समय के लिए, सॉफ्टवेयर में आम तौर पर स्वीकृत ज्ञान था: "यदि यह काम करता है, तो कुछ भी स्पर्श न करें।" अद्यतन करने से नई त्रुटियों को शुरू करने का जोखिम होता है; बिना किसी इनाम के - यदि आपको एक नई सुविधा की आवश्यकता नहीं है, तो जोखिम क्यों लें? यह दृष्टिकोण दो पहलुओं की अनदेखी करता है। सबसे पहले, एक क्रमिक उन्नयन की लागत। सॉफ्टवेयर में, कोड में परिवर्तन करने की जटिलता रैखिक पैमाने पर नहीं होती है: एक छोटे से बड़े परिवर्तन की तुलना में दस छोटे परिवर्तन कम काम और आसान होते हैं। दूसरे, पहले से ही सही त्रुटियों का पता लगाने की कठिनाई। विशेष रूप से सुरक्षा संदर्भ में, जहां ज्ञात त्रुटियों का सक्रिय रूप से शोषण किया जाता है, हर दिन इसे अपडेट किए बिना उन जोखिमों को बढ़ाता है जो हमलावर पुराने कोड में बग का लाभ उठा सकते हैं।

उदाहरण के लिए, इक्विफैक्स की 2017 की कहानी पर विचार करें, जिसे अधिकारियों ने कांग्रेस के सामने गवाही में विस्तार से बताया था। 7 मार्च को, Apache Struts में एक नई भेद्यता की खोज की गई और एक पैच संस्करण जारी किया गया। 8 मार्च को, इक्विफैक्स ने अपाचे स्ट्रट्स के किसी भी उपयोग को अपडेट करने की आवश्यकता के यूएस-सीईआरटी अधिसूचना प्राप्त की। इक्विफैक्स ने क्रमशः 9 और 15 मार्च को स्रोत कोड और नेटवर्क का एक स्कैन लॉन्च किया; इंटरनेट पर एक भी स्कैन असुरक्षित वेब सर्वर नहीं मिला। 13 मई को, हमलावरों को ऐसे सर्वर मिले जो इक्विफैक्स विशेषज्ञों को नहीं मिले। उन्होंने एपाक्सैक्स नेटवर्क को हैक करने के लिए अपाचे स्ट्रट्स की भेद्यता का इस्तेमाल किया और अगले दो महीनों में 148 मिलियन लोगों के बारे में विस्तृत व्यक्तिगत और वित्तीय जानकारी चुराई। आखिरकार, 29 जुलाई को इक्विफैक्स ने एक हैक को देखा और 4 सितंबर को सार्वजनिक रूप से इसकी घोषणा की। सितंबर के अंत तक, इक्विफैक्स के सीईओ, साथ ही सीआईओ और सीएसओ ने इस्तीफा दे दिया था, और कांग्रेस में जांच शुरू हो गई थी।

इक्विफैक्स का अनुभव इस तथ्य की ओर जाता है कि हालांकि पैकेज मैनेजर उन संस्करणों को जानते हैं जो वे निर्माण के दौरान उपयोग करते हैं, आपको उत्पादन में तैनाती के दौरान इस जानकारी को ट्रैक करने के लिए अन्य तंत्रों की आवश्यकता होती है। गो भाषा के लिए, हम प्रत्येक बाइनरी में मैनिफ़ेस्ट मेनिफ़ेस्ट सहित स्वचालित रूप से प्रयोग कर रहे हैं ताकि परिनियोजन प्रक्रियाएँ निर्भरता के लिए बायनेरिज़ को स्कैन कर सकें, जिन्हें अद्यतन करने की आवश्यकता है। गो यह जानकारी रन टाइम पर भी उपलब्ध कराती है, इसलिए सर्वर ज्ञात त्रुटियों के डेटाबेस तक पहुँच सकते हैं और स्वतंत्र रूप से निगरानी प्रणाली को रिपोर्ट कर सकते हैं जब उन्हें अद्यतन करने की आवश्यकता होती है।

एक त्वरित अद्यतन महत्वपूर्ण है, लेकिन अद्यतन का मतलब है कि परियोजना में नया कोड जोड़ना, जिसका अर्थ नए संस्करण के आधार पर निर्भरता उपयोग के जोखिम मूल्यांकन को अद्यतन करना चाहिए। कम से कम, आप अद्यतन संस्करण में वर्तमान संस्करण से किए जा रहे परिवर्तनों को दर्शाने वाले अंतरों को देखना चाहते हैं, या अद्यतन कोड में सबसे अधिक संभावित समस्या क्षेत्रों की पहचान करने के लिए कम से कम रिलीज नोट्स पढ़ें। यदि बहुत सारे कोड बदलते हैं, तो अंतर समझना मुश्किल है, यह भी जानकारी है जिसे आप अपने जोखिम मूल्यांकन को अपडेट करने में शामिल कर सकते हैं।

इसके अलावा, आपको परियोजना के लिए विशेष रूप से लिखे गए परीक्षणों को फिर से चलाना होगा ताकि यह सुनिश्चित किया जा सके कि अद्यतन पैकेज कम से कम पहले के संस्करण के रूप में परियोजना के लिए उपयुक्त है। यह भी अपने खुद के पैकेज परीक्षण फिर से चलाने के लिए समझ में आता है। यदि पैकेज की अपनी निर्भरताएं हैं, तो यह संभव है कि प्रोजेक्ट कॉन्फ़िगरेशन पैकेज के लेखकों द्वारा उपयोग किए गए की तुलना में इन निर्भरताओं (पुराने या नए) के अन्य संस्करणों का उपयोग करता है। अपने स्वयं के पैकेज परीक्षणों को चलाने से आप कॉन्फ़िगरेशन के लिए विशिष्ट समस्याओं को जल्दी से पहचान सकते हैं।

फिर से, अपडेट को पूरी तरह से स्वचालित होने की आवश्यकता नहीं है। अपडेट किए गए संस्करणों को तैनात करने से पहले , सुनिश्चित करें कि वे आपके पर्यावरण के लिए उपयुक्त हैं ।

यदि अद्यतन प्रक्रिया में पहले से लिखे गए एकीकरण और योग्यता परीक्षणों को फिर से निष्पादित करना शामिल है, तो ज्यादातर मामलों में अपडेट में देरी एक त्वरित अपडेट की तुलना में अधिक जोखिम भरा है।

महत्वपूर्ण सुरक्षा अद्यतन के लिए विंडो विशेष रूप से छोटी है। इक्विफैक्स के हैक होने के बाद, फोरेंसिक सुरक्षा टीमों को सबूत मिले कि हमलावरों (संभवतः अलग) ने 10 मार्च को प्रभावित सर्वरों पर अपाचे स्ट्रट्स की भेद्यता का सफलतापूर्वक फायदा उठाया, इसके तीन दिन बाद ही इसका सार्वजनिक रूप से खुलासा किया गया था। लेकिन उन्होंने केवल एक टीम को वहां लॉन्च किया whoami।

अपने व्यसनों को देखो

इतना सब होने के बाद भी काम खत्म नहीं हुआ है। निर्भरता की निगरानी करना जारी रखना महत्वपूर्ण है और, कुछ मामलों में, यहां तक ​​कि उन्हें छोड़ देना चाहिए।

सबसे पहले, सुनिश्चित करें कि आप पैकेजों के विशिष्ट संस्करणों का उपयोग करना जारी रखते हैं। अधिकांश पैकेज प्रबंधक अब आपको आसानी से या स्वचालित रूप से पैकेज के दिए गए संस्करण के लिए अपेक्षित स्रोत कोड के क्रिप्टोग्राफ़िक हैश रिकॉर्ड करने की अनुमति देते हैं, और फिर पैकेज को किसी अन्य कंप्यूटर या परीक्षण वातावरण में दोबारा डाउनलोड करने पर इस हैश की जांच करते हैं। यह सुनिश्चित करता है कि बिल्ड उसी निर्भरता स्रोत कोड का उपयोग करेगा जिसे आपने परीक्षण और परीक्षण किया था। इस तरह के चेक ने हमलावर को रोकाevent-stream, स्वचालित रूप से पहले से जारी संस्करण 3.3.5 में दुर्भावनापूर्ण कोड इंजेक्ट करें। इसके बजाय, हमलावर को एक नया संस्करण 3.3.6 बनाना था और लोगों को अपडेट करने की प्रतीक्षा करनी चाहिए (ध्यान से बदलावों को देखे बिना)।

नई अप्रत्यक्ष निर्भरताओं के उद्भव की निगरानी करना भी महत्वपूर्ण है: अपडेट आसानी से नए पैकेज पेश कर सकते हैं, जिस पर अब आपकी परियोजना की सफलता निर्भर करती है। वे आपके ध्यान के योग्य भी हैं। मामले में, event-streamदुर्भावनापूर्ण कोड किसी अन्य पैकेज में छिपा हुआ था flatMap-stream, जिसे नए संस्करण में event-streamएक नई निर्भरता के रूप में जोड़ा गया था।

रेंगने की निर्भरता भी परियोजना के आकार को प्रभावित कर सकती है। Google Sawzall के विकास के दौरानलॉग की JIT- प्रसंस्करण भाषा - अलग-अलग समय पर, लेखकों ने पाया कि मुख्य दुभाषिया बाइनरी में न केवल जेआईटी सॉजॉल है, बल्कि (अप्रयुक्त) पोस्टस्क्रिप्ट, पायथन और जावास्क्रिप्ट दुभाषिए भी हैं। हर बार, अपराधी कुछ सज़ल लाइब्रेरी द्वारा घोषित अप्रयुक्त निर्भरता के रूप में निकला, इस तथ्य के साथ कि Google बिल्ड सिस्टम ने पूरी तरह से नई निर्भरता का उपयोग किया। यही कारण है कि अप्रयुक्त पैकेज आयात करते समय गो संकलक एक त्रुटि फेंकता है।

बदलती निर्भरता का उपयोग करने के अपने निर्णय को संशोधित करने के लिए अद्यतन करना स्वाभाविक समय है। किसी भी लत की समय-समय पर समीक्षा करना भी महत्वपूर्ण है जो नहीं करता हैबदल रहा है। क्या यह प्रशंसनीय लगता है कि कोई सुरक्षा समस्या या अन्य त्रुटियों को ठीक करने के लिए नहीं हैं? क्या परियोजना को छोड़ दिया गया है? शायद यह इस निर्भरता के प्रतिस्थापन की योजना बनाने का समय है।

प्रत्येक निर्भरता के सुरक्षा लॉग को दोबारा जांचना भी महत्वपूर्ण है। उदाहरण के लिए, अपाचे स्ट्रट्स ने 2016, 2017 और 2018 में रिमोट कोड निष्पादन में गंभीर कमजोरियों का खुलासा किया। यहां तक ​​कि अगर आपके पास कई सर्वर हैं जो इसे शुरू करते हैं और जल्दी से इसे अपडेट करते हैं, तो इस तरह के ट्रैक रिकॉर्ड से पता चलता है कि क्या यह इसका उपयोग करने के लायक है।

निष्कर्ष

सॉफ्टवेयर पुन: उपयोग का युग अंत में आ गया है, और मैं लाभ को कम नहीं करना चाहता: यह डेवलपर्स के लिए एक अत्यंत सकारात्मक परिवर्तन लाया। हालांकि, हमने संभावित परिणामों पर पूरी तरह से विचार किए बिना इस परिवर्तन को अपनाया। निर्भरता पर भरोसा करने के पूर्व कारण उसी समय प्रासंगिकता खो देते हैं जब हमारे पास पहले से अधिक निर्भरता होती है।

विशिष्ट निर्भरता का महत्वपूर्ण विश्लेषण जो मैंने इस लेख में वर्णित किया है वह महत्वपूर्ण मात्रा में काम का प्रतिनिधित्व करता है और नियम के बजाय अपवाद बना हुआ है। लेकिन मुझे संदेह है कि ऐसे डेवलपर हैं जो वास्तव में हर संभव नई लत के लिए ऐसा करने के लिए कड़ी मेहनत कर रहे हैं। मैंने इस काम का कुछ हिस्सा अपनी खुद की निर्भरता के लिए किया। मूल रूप से, संपूर्ण समाधान निम्न के लिए आता है: "देखते हैं क्या होता है।" बहुत बार, कुछ और बहुत अधिक प्रयास लगता है।

लेकिन कोपे और इक्विफैक्स हमले वास्तविक समस्याओं की स्पष्ट चेतावनी हैं कि आज हम सॉफ्टवेयर निर्भरता का उपयोग कैसे करते हैं। हमें चेतावनियों को नजरअंदाज नहीं करना चाहिए। मैं तीन सामान्य सिफारिशें प्रदान करता हूं।

1. . , , , . , .
2. . , , . , , . , , , .
3. . . . , . , , . , , API. .

बहुत सारे अच्छे सॉफ्टवेयर हैं। चलो एक साथ काम करते हैं और यह पता लगाते हैं कि इसे सुरक्षित रूप से कैसे उपयोग किया जाए।