ओपन सोर्स VPN क्लाइंट: कोड क्या साबित करता है और क्या नहीं
सार्वजनिक रिपॉज़िटरी स्रोत कोड के बारे में साक्ष्य है, आपके द्वारा इंस्टॉल किए गए बिल्ड के बारे में नहीं और उसके पीछे के सर्वरों के बारे में भी नहीं। रिलीज़ को मिलाएँ, फिर समीक्षा का दायरा बढ़ाएँ।
स्रोत प्रकाशित है, लाइसेंस साफ़ है, और कनेक्शन अब भी शुरू से अंत तक सत्यापित नहीं किया जा सकता। यह अंतर सामान्य है, और यह कोई घोटाला नहीं है। कोड प्रकाशित करने से एक घटक ऐसे लोगों के लिए जाँचने योग्य हो जाता है जिन्हें आमंत्रित नहीं किया गया था, और यह एक वास्तविक और असामान्य गुण है। इससे यह नहीं निकलता कि आपने जो बाइनरी इंस्टॉल की वह उसी कोड से आई है, या प्रदाता दूसरी ओर जो कुछ चलाता है उसमें से कुछ भी जाँचा गया है।
घटक को उत्पाद से अलग करें
चार चीज़ें ओपन सोर्स का लेबल ले सकती हैं, और वे शायद ही कभी सब खुली होती हैं। क्लाइंट एप्लिकेशन वही है जो लोग मानते हैं। उसके नीचे प्रोटोकॉल का कार्यान्वयन एक अलग कलाकृति है, कभी लाइब्रेरी और कभी ट्री के भीतर का कोड। सर्वर सॉफ़्टवेयर तीसरा है, और प्रदाता का अपना ढाँचा, अकाउंट पोर्टल और सहायता उपकरण चौथा। हर एक स्वतंत्र रूप से खुला या बंद हो सकता है।
इसलिए "हमारा ऐप ओपन सोर्स है" जैसे कथन पहली वस्तु का वर्णन करते हैं और बाकी को अनुत्तरित छोड़ देते हैं, जो बेईमानी नहीं बल्कि श्रेणी की खिसकन है। उपयोगी प्रश्न यह है कि कौन-सी रिपॉज़िटरी, किस टैग पर, उस घटक से मेल खाती है जिस पर आप भरोसा कर रहे हैं।
यह अंतर यह भी समझाता है कि समान खुले क्लाइंट वाले दो उत्पाद बहुत अलग आश्वासन क्यों दे सकते हैं। क्लाइंट वह हिस्सा है जिसे आप जाँच सकते हैं; ऑपरेटर का व्यवहार वह हिस्सा है जिसे आपको दूसरे साधनों से आँकना है।
इंस्टॉल किए गए बिल्ड को प्रकाशित टैग से मिलाएँ
रिपॉज़िटरी मंशा का रिकॉर्ड है; आपकी डिस्क पर मौजूद बाइनरी वह चीज़ है जो चलती है। इस अंतर को बंद करना एक यांत्रिक अभ्यास है, और इसकी शुरुआत यह पहचानने से होती है कि ठीक क्या इंस्टॉल है, न कि डाउनलोड पृष्ठ ने क्या विज्ञापित किया था।
| Component | What inspection can show | What it leaves untouched |
|---|---|---|
| Client source | How profiles, packets and optional telemetry are handled | Whether the shipped binary matches that source |
| Build output | Whether a declared build reproduces a matching artefact | Whether the source is correct or the toolchain is clean |
| Server software | What the implementation is capable of logging | What the operator actually configures and retains |
| Account and support systems | Almost nothing, unless they are separately published | Everything about how those systems treat your data |
पैकेज मेटाडेटा आपको संस्करण और मूल बताता है, जिससे पुराने या बदले गए पैकेज का सामान्य मामला बाहर हो जाता है। यह आपको नहीं बताता कि वह पैकेज कैसे संकलित हुआ था, और ठीक इसी प्रश्न का उत्तर देने के लिए पुनरुत्पादनयोग्य बिल्ड हैं। पुनरुत्पादनयोग्य बिल्ड किसी स्वतंत्र पक्ष को उसी स्रोत से फिर से बनाने और आउटपुट की बाइट-दर-बाइट तुलना करने देते हैं, ताकि असंगति संदेह के बजाय साक्ष्य बन जाए।
सटीक मेल भी लोगों की अपेक्षा से कम साबित करता है। यह दिखाता है कि कलाकृति स्रोत और बिल्ड नुस्खे से मेल खाती है, न कि स्रोत दोष-रहित है, और न कि इस्तेमाल की गई टूलचेन भरोसेमंद थी। दोनों जानने योग्य हैं, पर ये अलग दावे हैं।
dpkg -S /usr/bin/wg
apt-cache policy wireguard-tools
sha256sum /usr/bin/wgलक्षण आम तौर पर कहाँ से शुरू होता है
इस पढ़ने को प्रेरित करने वाली शिकायत शायद ही कभी "कोड बंद है" होती है। यह आम तौर पर एक ठोस अवलोकन होता है: कोई क्लाइंट जो कहीं अप्रत्याशित रूप से संपर्क करता है, रिलीज़ नोट्स से भिन्न संस्करण, या ऐसी सहायता प्रक्रिया जो टनल की ज़रूरत से अधिक माँगती है। इनमें से हर बिंदु अलग घटक की ओर संकेत करता है।
क्लाइंट से अप्रत्याशित नेटवर्क ट्रैफ़िक क्लाइंट स्रोत का प्रश्न है, और कनेक्शन खोलने वाले कोड पथ को पढ़कर इसका उत्तर दिया जा सकता है। संस्करण की असंगति पैकेजिंग का प्रश्न है। पहचान दस्तावेज़ माँगने वाली सहायता प्रक्रिया अकाउंट सिस्टम का प्रश्न है, और कोई भी क्लाइंट ऑडिट इसे हल नहीं करेगा।
घटक का नाम लेने से अस्पष्ट अविश्वास एक ठोस जाँच में बदल जाता है। ठोस जाँच का उत्तर दिया जा सकता है, उससे बहस की जा सकती है या उसे बंद किया जा सकता है। विकल्प है अगले कदम के बिना स्थायी संदेह।
समीक्षा कहाँ तक नहीं पहुँच सकती, और उसके बजाय क्या करें
प्रदाता के सर्वरों पर डेटा रखना क्लाइंट की पहुँच से बाहर है। बिलिंग पोर्टल, धोखाधड़ी-जाँच विक्रेता या अटैचमेंट रखने वाली सहायता डेस्क का व्यवहार भी वैसा ही है। "हमने सेवा का ऑडिट किया" तक खींची गई क्लाइंट समीक्षा ऐसा दावा करती है जिसे साक्ष्य का समर्थन नहीं है।
पढ़ें कि ऑपरेटर डेटा रखने और अनुरोधों के बारे में क्या प्रकाशित करता है, तारीख नोट करें, और इसे माप नहीं बल्कि हितधारक पक्ष का बयान मानें। यह साक्ष्य का कमज़ोर रूप है, और दोबारा सुनाते समय उसे बढ़ाने से बेहतर है अंतर को स्पष्ट कहना।
फिर जो आपके पास है उसे कई इनपुट में से एक के रूप में इस्तेमाल करें: इंस्टॉल की गई रिलीज़ की पहचान, क्या सॉफ़्टवेयर का रखरखाव होता है, क्लाइंट कैसे कॉन्फ़िगर है, और ऑपरेटर अपने सिस्टम के बारे में क्या कहता है। ओपन कोड उस आकलन को एक बिंदु पर मज़बूत करता है। यह बाकी की जगह नहीं लेता।
ऑडिट के दावे में हमेशा उसके घटकों और संस्करणों के नाम होने चाहिए। अगर कोई रिपोर्ट यह नहीं बता सकती कि उसने कौन-सी रिपॉज़िटरी और कौन-सा बिल्ड जाँचा, तो वह उत्पाद नहीं बल्कि मंशा का वर्णन कर रही है।