ഓപ്പൺ സോഴ്സ് 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രോഗലക്ഷണം സാധാരണയായി എവിടെ തുടങ്ങുന്നു
ഈ വായനയ്ക്ക് കാരണമാകുന്ന പരാതി അപൂർവമായി "കോഡ് അടച്ചതാണ്" എന്നതാണ്. സാധാരണയായി ഒരു നിർദ്ദിഷ്ട നിരീക്ഷണമാണ്: അപ്രതീക്ഷിതമായ എവിടേക്കോ വിളിക്കുന്ന ക്ലയന്റ്, റിലീസ് കുറിപ്പുകളിൽ നിന്ന് വ്യത്യസ്തമായ പതിപ്പ്, അല്ലെങ്കിൽ ടണലിന് ആവശ്യമായതിലും കൂടുതൽ ആവശ്യപ്പെടുന്ന പിന്തുണാ പ്രക്രിയ. ഇവയിൽ ഓരോന്നും വ്യത്യസ്ത ഘടകത്തിലേക്ക് വിരൽ ചൂണ്ടുന്നു.
ക്ലയന്റിൽ നിന്നുള്ള അപ്രതീക്ഷിത നെറ്റ്വർക്ക് ട്രാഫിക് ക്ലയന്റ് സോഴ്സ് കോഡിന്റെ ചോദ്യമാണ്, കണക്ഷൻ തുറക്കുന്ന കോഡ് പാത വായിച്ച് അതിന് ഉത്തരം നൽകാം. പതിപ്പ് വ്യത്യാസം പാക്കേജിംഗിന്റെ ചോദ്യമാണ്. ഐഡന്റിറ്റി രേഖകൾ ആവശ്യപ്പെടുന്ന പിന്തുണാ പ്രക്രിയ അക്കൗണ്ട് സിസ്റ്റത്തിന്റെ ചോദ്യമാണ്, ഏതെങ്കിലും ക്ലയന്റ് ഓഡിറ്റ് അത് പരിഹരിക്കില്ല.
ഘടകത്തിന് പേര് നൽകുന്നത് അവ്യക്തമായ അവിശ്വാസത്തെ നിർദ്ദിഷ്ട പരിശോധനയാക്കി മാറ്റുന്നു. നിർദ്ദിഷ്ട പരിശോധനയ്ക്ക് ഉത്തരം നൽകാം, അതിനോട് തർക്കിക്കാം, അല്ലെങ്കിൽ അത് അവസാനിപ്പിക്കാം. ബദൽ അടുത്ത ചുവടില്ലാത്ത ശാശ്വത സംശയമാണ്.
അവലോകനം എത്താത്തത്, പകരം എന്ത് ചെയ്യണം
ദാതാവിന്റെ സർവറുകളിലെ സംഭരണം ക്ലയന്റിന്റെ പരിധിക്ക് പുറത്താണ്. ബില്ലിംഗ് പോർട്ടൽ, തട്ടിപ്പ് പരിശോധനാ വിതരണക്കാരൻ, അല്ലെങ്കിൽ അറ്റാച്ചുമെന്റുകൾ സൂക്ഷിക്കുന്ന പിന്തുണാ ഡെസ്ക് എന്നിവയുടെ പ്രവർത്തനവും അങ്ങനെതന്നെ. "ഞങ്ങൾ സേവനം ഓഡിറ്റ് ചെയ്തു" വരെ നീട്ടുന്ന ക്ലയന്റ് അവലോകനം തെളിവ് പിന്തുണയ്ക്കാത്ത ഒരു അവകാശവാദം ഉന്നയിക്കുന്നു.
ഓപ്പറേറ്റർ സംഭരണത്തെയും അഭ്യർത്ഥനകളെയും കുറിച്ച് പ്രസിദ്ധീകരിക്കുന്നത് വായിക്കുക, തീയതി രേഖപ്പെടുത്തുക, അതിനെ അളവല്ല, മറിച്ച് താൽപ്പര്യമുള്ള കക്ഷിയുടെ പ്രസ്താവനയായി കാണുക. അത് തെളിവിന്റെ ദുർബല രൂപമാണ്, വീണ്ടും പറയുമ്പോൾ അത് ഉയർത്തുന്നതിനേക്കാൾ വ്യത്യാസം വ്യക്തമായി പറയുന്നതാണ് ഉപയോഗപ്രദം.
പിന്നെ നിങ്ങൾക്കുള്ളത് നിരവധി ഇൻപുട്ടുകളിൽ ഒന്നായി ഉപയോഗിക്കുക: ഇൻസ്റ്റാൾ ചെയ്ത റിലീസിന്റെ ഐഡന്റിറ്റി, സോഫ്റ്റ്വെയർ പരിപാലിക്കപ്പെടുന്നുണ്ടോ, ക്ലയന്റ് എങ്ങനെ കോൺഫിഗർ ചെയ്തിരിക്കുന്നു, ഓപ്പറേറ്റർ സ്വന്തം സിസ്റ്റങ്ങളെക്കുറിച്ച് എന്ത് പറയുന്നു. തുറന്ന കോഡ് ആ വിലയിരുത്തൽ ഒരു ഘട്ടത്തിൽ ശക്തമാക്കുന്നു. അത് ബാക്കിയുള്ളതിന് പകരമാകുന്നില്ല.
ഓഡിറ്റ് അവകാശവാദം എപ്പോഴും അതിന്റെ ഘടകങ്ങളും പതിപ്പുകളും പേരിടണം. ഏത് റിപ്പോസിറ്ററിയും ഏത് ബിൽഡും പരിശോധിച്ചു എന്ന് ഒരു റിപ്പോർട്ടിന് പറയാൻ കഴിയില്ലെങ്കിൽ, അത് ഉൽപ്പന്നത്തെയല്ല, ഉദ്ദേശത്തെയാണ് വിവരിക്കുന്നത്.