अपनी निर्भरता का परीक्षण करने का अच्छा कारण: एजीपीएल-संस्करण

यहाँ आप BSD, MIT और Apache2 लाइसेंस के तहत कोड लेते हैं और व्हिस्की को उड़ाते हैं, और फिर - bam! - दूसरी शिफ्ट, और ट्रांजेक्टिव डिपेंडेंस में एजीपीएल के तहत कोड तैयार किया गया है। हम इस पर नज़र रखने की कोशिश करते हैं और अंडर-फिनिश के बजाय ओवरटेक करना पसंद करते हैं।



अपनी किसी भी परियोजना में नई निर्भरता जोड़ने से पहले, मैं हमेशा एक बुनियादी जाँच करता हूँ। मैं क्या जाँच (मानक जाँच सूची):

• कोड किस लाइसेंस के तहत जारी किया जाता है?
• लेखक कौन है?
• क्या त्रुटि ट्रैकर में कोई गंभीर अनसुलझे मुद्दे हैं?
• क्या त्रुटि ट्रैकर में गंभीर कीड़े का इतिहास है?
• पुल-क्वैस्ट के लिए कोड की समीक्षा कैसे होती है?

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

यह काफी बड़ी मात्रा में काम है, लेकिन यह आवश्यक है कि घटना-धारा जैसे हमलों का शिकार न बनें। और हाल ही में, मुझे निर्भरता की जांच करने के लिए एक और अच्छा कारण याद दिलाया गया था। उस समय मैं Go पर WebAuthn के लिए Duo से सक्रिय रूप से विज्ञापित पुस्तकालय की समीक्षा कर रहा था, यह यहाँ है: github.com/duo-labs/webauthn ।

यह सब इस तथ्य से शुरू हुआ कि मैंने कुछ "ब्राउन एम एंड एम" पर ध्यान दिया:

• डेटा इस तथ्य के बावजूद कि यह एक पुस्तकालय है, स्टडआउट में लॉग इन किया गया था।
• कोड का स्टॉक किया गया था।

निश्चित रूप से, ये मामूली मुद्दे केवल कुछ और के हानि पहुँचाने वाले थे: जब मैंने एक सकर्मक निर्भरता ( github.com/katzenpost/core/crypto/eddsa ) में से एक की समीक्षा शुरू की, तो AGPLv3 हेडर मुझे मिले।

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

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

दूसरे शब्दों में, यदि आपने सार्वजनिक वेब एप्लिकेशन में github.com/duo-labs/webauthn का उपयोग किया है, तो आपका वेब एप्लिकेशन अब खुला स्रोत होना चाहिए।

इस निर्भरता के बारे में सबसे अपमानजनक बात यह है कि यह golang.org/x/crypto/ed25519 - गो के अर्ध- मानक "x" पुस्तकालयों में से एक है ।

वास्तव में, github.com/duo-labs/webauthn मूल रूप से उपयोग किए जाने वाले golang.org/x/crypto/ed25519 के समान है। प्रतिस्थापन एक बाहरी सहयोग के पुल-क्वेस्ट के दौरान हुआ, जिसे "अपने क्षेत्र में समेकित COSE चीजें" कहा जाता है। कोड के भाग को एक फ़ाइल से दूसरी फ़ाइल में स्थानांतरित करने की प्रक्रिया में, इस पुल अनुरोध ने चुपचाप OKPPublicKeyData.Verify के कार्यान्वयन को बदल दिया।

यहाँ OKPPublicKeyData.Verify है जो OKPPublicKeyData.Verify का उपयोग करता है:

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) return ed25519.Verify(k.XCoord, h.Sum(nil), sig), nil } 

और यहाँ OKPPublicKeyData.Verify , जो OKPPublicKeyData.Verify लाइसेंस प्राप्त github.com/katzenpost/core/crypto/eddsa का उपयोग करता है:

 // Verify Octet Key Pair (OKP) Public Key Signature func (k *OKPPublicKeyData) Verify(data []byte, sig []byte) (bool, error) { f := HasherFromCOSEAlg(COSEAlgorithmIdentifier(k.PublicKeyData.Algorithm)) h := f() h.Write(data) var oKey eddsa.PublicKey err := oKey.FromBytes(k.XCoord) if err != nil { return false, err } return oKey.Verify(h.Sum(nil), sig), nil } 

इस बदलाव का कोई स्पष्टीकरण नहीं दिया गया था। पुलियोक्वेस्ट समीक्षा दो डुओ कर्मचारियों द्वारा आयोजित की गई थी, इसे मंजूरी दे दी, और इसे वापस आयोजित किया।

इसीलिए मैं कोड को स्थानांतरित करने वाले पुल अनुरोधों के लिए अनुरोध स्वीकार नहीं करना चाहता। यहां तक ​​कि अगर कोड का नया संगठन पिछले एक से बेहतर है, तो जांच के लिए लिया गया समय "नई पुल-क्वेस्ट कुछ अति-उपयोगी होता है" बहुत अधिक समय तक खाता है।

मैंने AGPL लाइसेंस के साथ पुस्तकालय की निर्भरता के बारे में एक चेतावनी पोस्ट की , और डेवलपर्स ने golang.org/x/crypto/ed25519 लौटा दिया । इसके बावजूद, मैंने github.com/duo-labs/webauthn का उपयोग नहीं करने का निर्णय लिया। लाइब्रेरी और इसके आश्रितों के थोक को WebAuthn misfeature नामक सहायता के लिए डिज़ाइन किया गया है, जिसका उपयोग करने की मेरी इच्छा शून्य से कम है। मैंने सिर्फ एक बहुत सरल, सत्यापन-मुक्त पुस्तकालय लिखना समाप्त किया है, और यह ऊपर के दसवें हिस्से से छोटा है। जल्द ही मैं इसका सोर्स कोड खोलूंगा। इस लाइब्रेरी का विकास मौजूदा WebAuthn Go लाइब्रेरी के उपयोग की जिम्मेदारी से सस्ता था।

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

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