നിങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന പാക്കേജിനെ HTTPS-ഉം VPN-ഉം സ്ഥിരീകരിക്കുന്നില്ല

ഒരു അപ്ഡേറ്റ് പരാജയപ്പെടുന്നു, ത്രെഡിലെ നിർദ്ദേശം പരിചിതമായ വഴിയിലൂടെ പോകുന്നു: ട്രാഫിക് VPN വഴി കടക്കുന്നു, അതിനാൽ ഡൗൺലോഡ് വിശ്വസനീയമായിരിക്കണം, പിശക് കടന്നുപോകാൻ ഒപ്പ് പരിശോധന അയച്ചുവിടുന്നു। രണ്ട് വേറിട്ട ആശയങ്ങൾ ഒരു വാക്യത്തിൽ ലയിച്ചിരിക്കുന്നു। എൻക്രിപ്ഷൻ അറ്റങ്ങൾക്കിടയിലുള്ള വഴിയെ സംരക്ഷിക്കുന്നു; സ്ഥിരീകരണം തീരുമാനിക്കുന്നത് ബൈറ്റുകൾ നിങ്ങൾ ഉദ്ദേശിച്ച പ്രസാധകനിൽ നിന്നാണോ എന്നാണ്। ടണൽ ആദ്യത്തേത് നൽകുന്നു, രണ്ടാമത്തേതിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല।

ലക്ഷണം സാധാരണയായി ഒരു ഹോസ്റ്റിൽ, ഒരു ശേഖരത്തിൽ പരിശോധനാ പിശകാണ്, ബാക്കിയെല്ലാം സാധാരണയായി അപ്ഡേറ്റ് ചെയ്യുന്നു। ആ രൂപം തന്നെ നെറ്റ്വർക്ക് വഴി പ്രവർത്തിക്കുന്നു എന്നും അഭിപ്രായവ്യത്യാസം വിശ്വാസത്തെക്കുറിച്ചാണ് എന്നും പറയുന്നു।

വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്ന രണ്ട് നിയന്ത്രണങ്ങൾ

ഗതാഗത സുരക്ഷ ഉത്തരം നൽകുന്നത് ഈ ബന്ധത്തിന്റെ മറുവശത്ത് ആരുണ്ട്, വഴിയിൽ ആർക്കെങ്കിലും അത് വായിക്കാനോ മാറ്റാനോ കഴിയുമോ എന്നാണ്। പാക്കേജ് സ്ഥിരീകരണം ഉത്തരം നൽകുന്നത് ഈ വസ്തു നിങ്ങൾ ക്രമീകരിച്ച അധികാരി പ്രസിദ്ധീകരിച്ചതാണോ എന്നാണ്, നിങ്ങൾ നിയന്ത്രിക്കാത്ത ഒരു കണ്ണാടി വഴിയുള്ള ഡൗൺലോഡിനെ അത് അതിജീവിക്കണം।

ആ ചോദ്യങ്ങൾ അരികുകളിൽ മാത്രം ഒത്തുചേരുന്നു। കണ്ണാടിയിലെ ശരിയായ സർട്ടിഫിക്കറ്റ് കണ്ണാടി കണ്ണാടിയാണ് എന്ന് തെളിയിക്കുന്നു; കണ്ണാടിയിൽ മാറ്റമില്ലാത്ത പ്രസാധക ഉള്ളടക്കം ഉണ്ടെന്ന് അത് തെളിയിക്കുന്നില്ല। ഒപ്പിട്ട പാക്കേജ് പ്രസാധകൻ അതിൽ ഒപ്പിട്ടു എന്ന് തെളിയിക്കുന്നു; നെറ്റ്വർക്ക് ഏറ്റവും പുതിയ പതിപ്പ് എത്തിച്ചു എന്നോ നിങ്ങൾ ചൂണ്ടിയ ശേഖരം നിങ്ങളുടെ സ്ഥാപനം അംഗീകരിച്ചതാണ് എന്നോ അത് പറയുന്നില്ല।

പരിശോധനകൾ ഓഫാക്കി ആളുകൾ സൃഷ്ടിക്കുന്ന പരാജയാവസ്ഥ രണ്ടാമത്തെ ഉറപ്പിന്റെ ശാശ്വത നഷ്ടമാണ്, ഒരു വിജയകരമായ ഡൗൺലോഡിന് പകരം। ആ കൈമാറ്റം അത് പ്രധാനമാകുന്ന ദിവസം വരെ അദൃശ്യമാണ്।

apt യഥാർത്ഥത്തിൽ എന്താണ് സ്ഥിരീകരിക്കുന്നത്

APT യുടെ മാതൃക സ്ഥിരീകരിച്ച ആർക്കൈവ് ശൃംഖലയാണ്। ഒപ്പിട്ട റിലീസ് മെറ്റാഡാറ്റ ചെക്സം വഴി പാക്കേജ് സൂചികകളിലേക്ക് നയിക്കുന്നു, ആ സൂചികകൾ ചെക്സം വഴി വ്യക്തിഗത പാക്കേജ് ഫയലുകളിലേക്ക് നയിക്കുന്നു। ശൃംഖല പരിശോധിക്കുന്നതാണ് കണ്ണാടിയെ വിശ്വസനീയമല്ലാത്തതും എന്നാൽ ഉപയോഗയോഗ്യവുമാക്കുന്നത്: കണ്ണാടിക്ക് തോന്നിയത് നൽകാം, മെറ്റാഡാറ്റയുടെ ഒപ്പം APT അത് സ്വീകരിക്കുമോ എന്ന് തീരുമാനിക്കുന്നു।

ഇത് ബോധപൂർവം ഓരോ ഇൻസ്റ്റാൾ ചെയ്ത പാക്കേജിലും പരിപാലകന്റെ ഒപ്പ് പരിശോധിക്കുന്നതിന് തുല്യമല്ല, ആ വ്യത്യാസമാണ് ബഗ് റിപ്പോർട്ടുകളിൽ «പാക്കേജ് ഒപ്പിട്ടതാണ്» എന്നും «ആർക്കൈവ് സ്ഥിരീകരിച്ചതാണ്» എന്നും പരസ്പരം പകരം ഉപയോഗിക്കുന്നതിന്റെ കാരണം, അവ വ്യത്യസ്ത കാര്യങ്ങൾ അർത്ഥമാക്കുമ്പോൾ।

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

അപ്ഡേറ്റിന്റെ ഔട്ട്പുട്ട് വായിക്കുക, എക്സിറ്റ് കോഡ് മാത്രമല്ല। മെറ്റാഡാറ്റ പരാജയപ്പെട്ട ശേഖരത്തിന്റെ പേര് APT പറയുന്നു, ആ പേരാണ് അന്വേഷിക്കേണ്ട അതിർത്തി। ഒപ്പ് പരിശോധനയില്ലാതെ വിശ്വസനീയമെന്ന് അടയാളപ്പെടുത്തിയ ശേഖരം, അല്ലെങ്കിൽ അസുരക്ഷിത ശേഖരത്തിനുള്ള ഓവർറൈഡ്, ആരോ എടുത്ത ക്രമീകരണ തീരുമാനമാണ്, അത് വിശദീകരിക്കാൻ അദ്ദേഹത്തിന് കഴിയണം।

പുതുമ വീണ്ടും വേറിട്ട ഗുണമാണ്। സാധുവായി ഒപ്പിട്ട മെറ്റാഡാറ്റ ഫയൽ കഴിഞ്ഞ ആഴ്ച കണ്ടതിനേക്കാൾ പഴയതാകാം, അതിനാൽ റിലീസ് മെറ്റാഡാറ്റയ്ക്ക് കാലാവധിയുണ്ട്, അതിനാൽ ക്ലൈന്റിലെ ക്ലോക്ക് പ്രശ്നം കീ പ്രശ്നങ്ങൾ പോലെ തോന്നുന്ന പരിശോധനാ പിശകുകൾ ഉണ്ടാക്കാം।

dnf5 വേറിട്ട് എന്താണ് പരിശോധിക്കുന്നത്

RPM വശം രണ്ട് വ്യത്യസ്ത സ്വിച്ചുകൾ നൽകുന്നു, അവ കൂട്ടിക്കുഴച്ചാൽ എതിർദിശയിൽ അതേ തരം പിശക് ഉണ്ടാകും। ഒന്ന് പാക്കേജ് ഫയലുകൾക്ക് സാധുവായ ഒപ്പ് വേണമോ എന്ന് നിയന്ത്രിക്കുന്നു; മറ്റൊന്ന് ശേഖര മെറ്റാഡാറ്റ ഒപ്പിട്ടതായിരിക്കണമോ എന്ന് നിയന്ത്രിക്കുന്നു। അവ സ്വതന്ത്രമായി ക്രമീകരിക്കാം, ഒരു സിസ്റ്റത്തിന് ഒന്നിൽ കർശനവും മറ്റൊന്നിൽ അയവുള്ളതുമാകാം।

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

പാക്കേജ് ചോദ്യം ഇൻസ്റ്റാൾ ചെയ്ത പകർപ്പിന്റെ ഒപ്പ് മെറ്റാഡാറ്റ എങ്ങനെയിരിക്കുന്നു എന്ന് കാണിക്കുന്നു, ഇത് കർശനത അവകാശപ്പെടുന്ന ക്രമീകരണ ഫയലിനെതിരെ ഉപയോഗപ്രദമായ യാഥാർത്ഥ്യ പരിശോധനയാണ്। അത് പറയാത്തത് വിതരണത്തിന്റെ പിന്തുണയുള്ള നയമാണ്, ഫോറത്തിലെ പൊതുവായ «GPG പ്രവർത്തനക്ഷമമാക്കുക» നിർദ്ദേശത്തിന് പകരം അത് പിന്തുടരണം।

രണ്ട് മാനേജർമാർ വ്യത്യാസപ്പെടുന്നിടത്ത് വ്യത്യാസം വാസ്തുവിദ്യയുടേതാണ്, ഒന്ന് ദുർബലമാണ് എന്ന സൂചനയല്ല। രണ്ടും പ്രസാധക ഉള്ളടക്കം സ്ഥിരീകരിക്കുന്നു; അവ ഒപ്പ് ശൃംഖലയുടെ വ്യത്യസ്ത ബിന്ദുക്കളിൽ വയ്ക്കുന്നു।

ടണൽ എന്ത് ചേർക്കുന്നു, എന്ത് ചേർക്കുന്നില്ല

VPN ആവശ്യമായ റൂട്ട് നൽകാം, അപ്ഡേറ്റ് ട്രാഫിക് വിശ്വസനീയമല്ലാത്ത ആക്സസ് നെറ്റ്വർക്കിന് പുറത്ത് നിർത്താം, പ്രാദേശിക നിരീക്ഷകൻ കാണുന്നത് കുറയ്ക്കാം। ഇവ യഥാർത്ഥ പ്രവർത്തന നേട്ടങ്ങളാണ്, അവയൊന്നും പ്രസാധക സ്ഥിരീകരണമല്ല।

HTTPS സ്വന്തം ഉറപ്പ് ചേർക്കുന്നു, അത് തോന്നുന്നതിനേക്കാൾ ഇടുങ്ങിയതാണ്। നിങ്ങൾ ബന്ധിപ്പിച്ച TLS അറ്റം അത് സ്ഥിരീകരിക്കുന്നു। ആ അറ്റം ഒരു കണ്ണാടിയാണെങ്കിൽ, നിങ്ങൾ കണ്ണാടിയെ സ്ഥിരീകരിച്ചു, അത് നൽകുന്ന ആർക്കൈവ് ഉള്ളടക്കത്തെയല്ല। ഒപ്പിട്ട മെറ്റാഡാറ്റ ശൃംഖല ഉള്ളത് കൃത്യമായി ഈ സന്ദർഭത്തിനാണ്।

രണ്ട് നിയന്ത്രണങ്ങളിൽ ഒന്നും ലഭ്യത ഉറപ്പുനൽകുന്നില്ല। നെറ്റ്വർക്കിന് വിതരണം നിഷേധിക്കാം, സ്ഥിരീകരിച്ച വസ്തു സ്വയമേവ ഏറ്റവും പുതിയതല്ല। പൂട്ടിന്റെ ഐക്കൺ ഉള്ളതിൽ നിന്ന് അനുമാനിക്കുന്നതിന് പകരം പാക്കേജ് മാനേജറുടെ സ്വന്തം പുതുമാ നയം ഉപയോഗിക്കുക।

പരാജയപ്പെട്ട അതിർത്തി നിർണ്ണയിക്കുക

എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ഘട്ടം പേരിടുക: DNS പരിഹാരം, പ്രോക്സി അല്ലെങ്കിൽ റൂട്ട്, TLS അറ്റത്തിന്റെ അടയാളം, ആർക്കൈവ് സ്ഥിരീകരണം, പാക്കേജ് ഒപ്പ് പരിശോധനകൾ, അല്ലെങ്കിൽ ഇൻസ്റ്റലേഷൻ। ഓരോന്നിനും വേറിട്ട പിശക് രൂപവും വേറിട്ട ഉടമയുമുണ്ട്।

നെറ്റ്വർക്ക് വഴിയുടെ അറ്റകുറ്റപ്പണിയിൽ ഒരിക്കലും അജ്ഞാത ഒപ്പ് കീയെ വിശ്വസനീയമെന്ന് പ്രഖ്യാപിക്കുക, സർട്ടിഫിക്കറ്റുകൾ അവഗണിക്കുക, അല്ലെങ്കിൽ നിങ്ങൾ ആവശ്യപ്പെടാത്ത ശേഖര ക്രമീകരണം സ്വീകരിക്കുക എന്നിവ ഉൾപ്പെടരുത്। കീ യഥാർത്ഥത്തിൽ മാറിയെങ്കിൽ, വിതരണമോ ശേഖര ഉടമയോ നിങ്ങൾക്ക് പരിശോധിക്കാവുന്ന ചാനലിൽ പുതിയ കീ പ്രസിദ്ധീകരിക്കുന്നു, അതാണ് പ്രയോഗിക്കേണ്ട തിരുത്ത്।

ഏത് അതിർത്തി പരാജയപ്പെട്ടു, അതിന്റെ ഉടമ ആരാണ് എന്ന് എഴുതുക। അടുത്ത അപ്ഡേറ്റ് പരാജയം മറ്റൊരു അതിർത്തിയിലാകും, പട്ടിക ഉണ്ടായിരിക്കുന്നത് ടണൽ അപ്ഡേറ്റുകൾ സുരക്ഷിതമാക്കുന്നുണ്ടോ എന്ന മറ്റൊരു തർക്കത്തിന് പകരം അഞ്ച് മിനിറ്റ് നിർണ്ണയമാക്കി മാറ്റുന്നു।