खुला स्रोत 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लक्षण सामान्यतया कहाँबाट सुरु हुन्छ
यो पढाइको कारण बन्ने गुनासो विरलै "कोड बन्द छ" हुन्छ। सामान्यतया यो एउटा ठोस अवलोकन हो: अप्रत्याशित ठाउँमा सम्पर्क गर्ने क्लाइन्ट, रिलिज नोटभन्दा फरक संस्करण, वा सुरुङलाई चाहिनेभन्दा बढी माग्ने सहयोग प्रक्रिया। यीमध्ये प्रत्येकले फरक घटकतर्फ सङ्केत गर्छ।
क्लाइन्टबाट अप्रत्याशित सञ्जाल ट्राफिक क्लाइन्ट स्रोत कोडको प्रश्न हो, र जडान खोल्ने कोड मार्ग पढेर यसको उत्तर दिन सकिन्छ। संस्करणको अमिल्दोपन प्याकेजिङको प्रश्न हो। परिचयपत्र माग्ने सहयोग प्रक्रिया खाता प्रणालीको प्रश्न हो, र कुनै पनि क्लाइन्ट अडिटले त्यो समाधान गर्दैन।
घटकको नाम दिनुले अस्पष्ट अविश्वासलाई ठोस जाँचमा बदल्छ। ठोस जाँचको उत्तर दिन सकिन्छ, बहस गर्न सकिन्छ वा त्यसलाई बन्द गर्न सकिन्छ। विकल्प अर्को कदम नभएको स्थायी शङ्का हो।
समीक्षा कहाँसम्म पुग्न सक्दैन, र त्यसको सट्टा के गर्ने
प्रदायकका सर्भरमा राखिने डेटा क्लाइन्टको पहुँचबाहिर छ। बिलिङ पोर्टल, ठगी जाँच गर्ने आपूर्तिकर्ता वा संलग्नहरू राख्ने सहयोग डेस्कको व्यवहार पनि त्यस्तै हो। "हामीले सेवाको अडिट गर्यौं" सम्म तानिएको क्लाइन्ट समीक्षाले प्रमाणले समर्थन नगर्ने दाबी गर्छ।
अपरेटरले राख्ने र अनुरोधबारे के प्रकाशित गर्छ पढ्नुहोस्, मिति टिप्नुहोस्, र यसलाई मापन होइन तर सरोकारवाला पक्षको भनाइको रूपमा लिनुहोस्। त्यो प्रमाणको कमजोर रूप हो, र फेरि भन्दा फरक स्पष्ट भन्नु त्यसलाई उचाल्नुभन्दा उपयोगी हुन्छ।
त्यसपछि तपाईंसँग भएको कुरालाई धेरै इनपुटमध्ये एकका रूपमा प्रयोग गर्नुहोस्: स्थापित रिलिजको पहिचान, सफ्टवेयरको मर्मत हुन्छ वा हुँदैन, क्लाइन्ट कसरी कन्फिगर छ, र अपरेटरले आफ्नै प्रणालीबारे के भन्छ। खुला कोडले त्यो मूल्याङ्कनलाई एक बिन्दुमा बलियो बनाउँछ। यसले बाँकीलाई प्रतिस्थापन गर्दैन।
अडिटको दाबीले सधैं यसका घटक र संस्करणहरूको नाम लिनुपर्छ। यदि कुनै प्रतिवेदनले कुन रिपोजिटरी र कुन बिल्ड जाँच्यो भन्न सक्दैन भने, त्यो उत्पादन होइन मनसायको वर्णन गर्दैछ।