മിററിൽ നിന്നുള്ള VPN ഇൻസ്റ്റാളർ? ആദ്യം പ്രസാധകനെ പരിശോധിക്കുക

ടണൽ പ്രവർത്തിച്ചു, ഇന്റർഫേസ് ഉയർന്നു, സെഷൻ ഒരാഴ്ച സ്ഥിരമായി നിന്നു. അവയൊന്നും ഇൻസ്റ്റാളർ ആരാണ് നിർമ്മിച്ചതെന്ന് പറയുന്നില്ല. VPN ക്ലയന്റ് റൂട്ടുകൾ വീണ്ടും എഴുതാനും ക്രെഡൻഷ്യലുകൾ വായിക്കാനും മതിയായ അനുമതികളോടെ പ്രവർത്തിക്കുന്നു, അതിനാൽ പ്രസാധകൻ ഭീഷണി മാതൃകയുടെ ഭാഗമാണ്, അടിക്കുറിപ്പല്ല.

പരിശോധനകൾ ക്രമത്തിൽ ചെയ്ത് ആദ്യം പരാജയപ്പെടുന്നതിൽ നിർത്തുക. അവ വിലകുറഞ്ഞവയാണ്, ഓരോന്നും വ്യത്യസ്ത വിടവ് അടയ്ക്കുന്നു.

ആദ്യ ഘട്ടം: പ്രോജക്റ്റ് പേരിടുന്ന ചാനലിൽ നിന്ന് ഡൗൺലോഡ് ചെയ്യുക

ഓരോ പ്രോജക്റ്റും അതിന്റെ റിലീസുകൾ എവിടെയാണെന്ന് രേഖപ്പെടുത്തുന്നു, ആ പേജാണ് റഫറൻസ്. കമ്മ്യൂണിറ്റി ബിൽഡുകൾ, സ്റ്റോർ ലിസ്റ്റിംഗുകൾ, വെണ്ടർ പോർട്ടലുകൾ എന്നിവയെല്ലാം സാധുവായ ചാനലുകളാണ്. പ്രോജക്റ്റ് തന്നെ അതിലേക്ക് ചൂണ്ടിക്കാണിക്കുമ്പോൾ മാത്രമേ ഓരോന്നും സാധുവാകൂ. അതാണ് പരിശോധന, അത് ഔദ്യോഗികമായി കാണപ്പെടുന്നതിന് തുല്യമല്ല.

പ്രോജക്റ്റിന്റെ പേരിലുള്ള ഫയൽ ഒന്നും തെളിയിക്കുന്നില്ല. ഇൻസ്റ്റാളറിന്റെ പേര് മാറ്റുന്നത് ഒരു സെക്കൻഡ് നടപടിയാണ്, തിരയൽ ഫലം ആദ്യം കാണിക്കുന്നത് ആ പേരാണ്.

രണ്ടാം ഘട്ടം: അറിയപ്പെടുന്ന ഐഡന്റിറ്റിക്കെതിരെ ഒപ്പ് സ്ഥിരീകരിക്കുക

ഒപ്പ് സ്ഥിരീകരണം ഒരു ഇടുങ്ങിയ ചോദ്യത്തിന് നന്നായി ഉത്തരം നൽകുന്നു. ഒരു പ്രത്യേക ഐഡന്റിറ്റി ഈ ബൈനറിയിൽ ഒപ്പിട്ടു, ബൈനറി അതിനുശേഷം മാറിയിട്ടില്ല എന്ന് അത് പറയുന്നു. ഒരു ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു, മറ്റൊന്ന് നിരസിക്കുന്നു. ആ ഐഡന്റിറ്റി നിങ്ങൾ വിശ്വസിക്കാൻ ഉദ്ദേശിച്ചതാണോ എന്ന് അതിന് പറയാനാവില്ല.

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

സ്റ്റാറ്റസ് വാക്കല്ല, ഐഡന്റിറ്റി വായിക്കുക. സാധുവായ സർട്ടിഫിക്കറ്റുള്ള ബന്ധമില്ലാത്ത ഡെവലപ്പർക്കും സാധുവായ ഒപ്പ് ഉണ്ടാക്കാം. അംഗീകൃത പ്രസാധകനെ റിപ്പോർട്ട് ചെയ്യുന്ന ഓപ്പറേറ്റിംഗ് സിസ്റ്റം ആരോ ഒരു സർട്ടിഫിക്കറ്റിന് പണം നൽകി എന്ന് മാത്രമേ പറഞ്ഞിട്ടുള്ളൂ.

മൂന്നാം ഘട്ടം: ഹാഷ് സ്വതന്ത്രമായ ഉറവിടവുമായി താരതമ്യം ചെയ്യുക

ചെക്ക്സം ഒരു റഫറൻസ് മൂല്യവുമായുള്ള പൊരുത്തം തെളിയിക്കുന്നു. റഫറൻസ് ഡൗൺലോഡിനൊപ്പം എത്തിയെങ്കിൽ, രണ്ടും ഒരുമിച്ച് തെറ്റാകാം, താരതമ്യം ഇപ്പോഴും കടക്കും. മിക്ക ട്യൂട്ടോറിയലുകളിലെയും പരാജയ രീതി ഇതാണ്. ഹാഷ് അത് വിവരിക്കുന്ന ഫയലിന്റെ അതേ പേജിലുണ്ട്.

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

ഒരു പ്രോജക്റ്റ് ഒപ്പിട്ട ചെക്ക്സങ്ങളോ ഒപ്പിട്ട റിലീസ് മാനിഫെസ്റ്റോ പ്രസിദ്ധീകരിക്കുമ്പോൾ, ഓരോ ഫയലിലും വെവ്വേറെയല്ല, പട്ടികയിൽ ഒപ്പ് സ്ഥിരീകരിക്കുക. അങ്ങനെ ഒരു വിശ്വസ്ത റഫറൻസ് മുഴുവൻ റിലീസിനെയും ഉൾക്കൊള്ളുന്നു.

ഇൻസ്റ്റാളേഷന് ശേഷം: അപ്ഡേറ്റ് പാത നിലനിർത്തുക

ഇൻസ്റ്റാളേഷൻ കഴിഞ്ഞതിന് ശേഷവും പിന്തുണയുള്ള ചാനൽ പ്രധാനമാണ്. വീണ്ടും പാക്കേജ് ചെയ്ത ബിൽഡുകൾ സ്വന്തം അപ്ഡേറ്റർ വഹിച്ചേക്കാം, ആ അപ്ഡേറ്ററാണ് അടുത്ത മാസം എന്ത് പ്രവർത്തിക്കുമെന്ന് തീരുമാനിക്കുന്നത്. ഒരിക്കലും അപ്ഡേറ്റ് ചെയ്യാത്ത ബിൽഡ് കൂടുതൽ സുരക്ഷിതമല്ല. അത് കൂടുതൽ പഴയത് മാത്രമാണ്.

ക്ലയന്റ് എങ്ങനെ അപ്ഡേറ്റ് ചെയ്യണം, ആ ഘട്ടം ഒരു മാനേജ്മെന്റ് സിസ്റ്റത്തിന്റെ കൈവശമാണോ എന്ന് രേഖപ്പെടുത്തുക. ഉത്തരം ഒരു ഫോറത്തിൽ നിന്നുള്ള സ്വമേധയാ ഡൗൺലോഡ് ആണെങ്കിൽ, വിതരണ ശൃംഖലയുടെ ചോദ്യം ഒരിക്കലും ശരിക്കും അടഞ്ഞിട്ടില്ല.

രണ്ട് ഉത്ഭവങ്ങൾ, ഒന്നല്ല

ക്ലയന്റ് ഡെവലപ്പറും പ്രൊഫൈൽ പുറപ്പെടുവിക്കുന്നയാളും വെവ്വേറെ കക്ഷികളാണ്. ബന്ധമില്ലാത്ത ഓപ്പറേറ്ററിൽ നിന്നുള്ള പ്രൊഫൈൽ ഒരു ഔദ്യോഗിക ക്ലയന്റ് ഇംപോർട്ട് ചെയ്യുന്നത് സാധാരണ ക്രമീകരണമാണ്, പ്രൊഫൈലിന് സ്വന്തം പരിശോധന അർഹതയുണ്ട്: ആരാണ് അത് പുറപ്പെടുവിച്ചത്, എങ്ങനെ എത്തിച്ചു, സെർവർ സർട്ടിഫിക്കറ്റ് നിങ്ങൾ പ്രതീക്ഷിക്കുന്ന പേരുമായി പൊരുത്തപ്പെടുന്നുണ്ടോ.

നിങ്ങളുടെ കുറിപ്പുകളിൽ രണ്ട് ഉത്ഭവങ്ങളും തിരിച്ചറിയാവുന്നതായി സൂക്ഷിക്കുക. ഒരു ക്ലയന്റ് മാറ്റിസ്ഥാപിക്കപ്പെടുമ്പോഴോ ഒരു ഉപകരണം ബാക്കപ്പിൽ നിന്ന് പുനഃസ്ഥാപിക്കപ്പെടുമ്പോഴോ, ആ രണ്ട് വരികളാണ് അജ്ഞാതമായ ഒരു ബിൽഡോ അജ്ഞാതമായ ഒരു പ്രൊഫൈലോ ബാക്കി ഡാറ്റയോടൊപ്പം തിരികെ വരുന്നത് തടയുന്നത്.