कोई भी सुरक्षा समस्या ओपन सोर्स प्रोजेक्ट के लिए स्रोत नियंत्रण के लिए एक मजबूत नाम कुंजी जोड़ रही है?

Question

एक मजबूत नाम कुंजी (स्नैक फ़ाइल) दिया गया। क्या इस फ़ाइल को ओपन सोर्स प्रोजेक्ट के लिए स्रोत नियंत्रण में जोड़ने में कोई सुरक्षा समस्या है?

Answer 1

सरल उत्तर हाँ है और नहीं - यह उस उद्देश्य पर निर्भर करता है जिसके लिए आप मजबूत हैं- नाम पहली बार अपनी असेंबली पर हस्ताक्षर करें।

Strong-Name Signing पर एमएसडीएन पृष्ठ दो उद्देश्यों को संक्षेप में सारांशित करता है।

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

किसी भी सार्वजनिक रूप से वितरित लाइब्रेरी (डीएलएल) को मजबूत-नाम पर हस्ताक्षर किया जाना चाहिए, जब तक कि यह अंतिम उपयोगकर्ता द्वारा उपभोग किया जाता है। (यानी जब तक यह एक कार्यान्वयन विवरण या ऐसा नहीं होता है।)

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

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

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