npm पैकेज जाँचें—audit signatures उत्पत्ति का प्रमाण भी परखता है

|लेखक: QUASA संपादकीय टीम|6 मिनट पढ़ने का समय| 1
npm पैकेज जाँचें—audit signatures उत्पत्ति का प्रमाण भी परखता है

परियोजना में डाउनलोड हुए पैकेजों के रजिस्ट्री हस्ताक्षर और उपलब्ध निर्माण-उत्पत्ति प्रमाण परखने के लिए npm audit signatures चलाएँ। npm की आदेश-संदर्भिका के अनुसार यह आदेश दोनों प्रमाण जाँचता है; साधारण npm audit ज्ञात सुरक्षा कमजोरियों की रिपोर्ट देता है। भेद्यता रिपोर्ट साफ आने का मतलब हस्ताक्षर या उत्पत्ति प्रमाण का सत्यापन हो जाना नहीं है।

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

दोनों जाँचें अलग सवालों का जवाब देती हैं

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

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

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

परियोजना में आदेश किस क्रम से चलाएँ

स्थापित npm निर्भरता के एक संस्करण से रजिस्ट्री हस्ताक्षर और उपलब्ध उत्पत्ति प्रमाण की अलग जाँच जुड़ी है

जाँच उसी परियोजना की निर्देशिका में करें जिसकी स्थापित निर्भरताओं के बारे में निर्णय लेना है। केवल रजिस्ट्री में किसी पैकेज का नाम खोजने से परियोजना में वास्तव में उपयोग हो रहे संस्करणों की जाँच नहीं होती। पहले उपकरण का संस्करण और निर्भरताओं की स्थापना सुनिश्चित करें; उसके बाद प्रमाण और कमजोरियाँ अलग-अलग परखें।

  1. संस्करण देखें। npm --version चलाकर संख्या पढ़ें। यदि उपकरण आवश्यक न्यूनतम संस्करण से पुराना है, तो उसे अद्यतन करके संख्या फिर देखें। परियोजना में प्रयुक्त दूसरे औजारों के संस्करण से पैकेज प्रबंधक का संस्करण अनुमान से तय न करें।
  2. निर्भरताएँ स्थापित करें। परियोजना की लॉकफ़ाइल में दर्ज संस्करणों के अनुसार स्थापना चाहिए तो npm ci चलाएँ; सामान्य स्थापना के लिए npm install चलाएँ। स्थापना बीच में रुकती है तो पहले उसकी त्रुटि सुलझाएँ। अधूरी स्थापना पर चलाया गया आदेश पूरी परियोजना की निर्भरताओं के बारे में भरोसेमंद निष्कर्ष नहीं देगा।
  3. प्रकाशन प्रमाण जाँचें। अब पहले अनुच्छेद वाला हस्ताक्षर सत्यापन आदेश चलाएँ। परिणाम में सत्यापित रजिस्ट्री हस्ताक्षरों तथा उत्पत्ति प्रमाणों की जानकारी देखें। त्रुटि आए तो संदेश में दिए पैकेज का नाम और संस्करण दर्ज करें, ताकि समस्या को उसी प्रकाशित संस्करण से जोड़ सकें।
  4. कमजोरियाँ अलग जाँचें। पहले अनुच्छेद वाला साधारण भेद्यता जाँच आदेश चलाएँ। इसमें मिली कमजोरी को हस्ताक्षर की विफलता न मानें। इसी तरह हस्ताक्षर सत्यापन सफल होने को ज्ञात कमजोरियों की रिपोर्ट का विकल्प न समझें।

एक ही परियोजना में दोनों आदेशों के परिणाम अलग आ सकते हैं। किसी संस्करण का हस्ताक्षर सही हो सकता है और उसके लिए ज्ञात कमजोरी भी दर्ज हो सकती है। उलटी स्थिति भी संभव है: भेद्यता रिपोर्ट में उस संस्करण के लिए कोई दर्ज समस्या न हो, लेकिन प्रकाशन प्रमाण की जाँच त्रुटि दे। ऐसे परिणामों को मिलाकर एक ही सफलता या विफलता घोषित करने के बजाय प्रत्येक आदेश का संदेश उसके अपने उद्देश्य के अनुसार पढ़ें।

सफल परिणाम में क्या समझें

सफल जाँच में सत्यापित हस्ताक्षरों की संख्या, सत्यापित उत्पत्ति प्रमाणों की संख्या से अलग हो सकती है। रजिस्ट्री का हस्ताक्षर और प्रकाशक द्वारा दिया गया निर्माण-उत्पत्ति प्रमाण स्वतंत्र चीजें हैं। किसी पैकेज के साथ उत्पत्ति प्रमाण प्रकाशित ही नहीं किया गया हो तो उस पैकेज के लिए प्रमाण गिने जाने की अपेक्षा नहीं करनी चाहिए। इसलिए दोनों गिनतियाँ बराबर न दिखना अकेले सत्यापन विफल होने का संकेत नहीं है।

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

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

त्रुटि आए तो उसका अर्थ कैसे पहचानें

हस्ताक्षर देने वाली npm रजिस्ट्री में एक पैकेज संस्करण का हस्ताक्षर संबंध गायब दिखता है

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

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

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

यह भी पढ़ें:

साझा करें:

हमारे न्यूज़लेटर की सदस्यता लें

Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।

0