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 છેડાની ઓળખ, આર્કાઇવ પ્રમાણીકરણ, પેકેજ સહી ચકાસણી, અથવા ઇન્સ્ટોલેશન। દરેકનો અલગ ભૂલ-આકાર અને અલગ માલિક છે।

નેટવર્ક માર્ગનું સમારકામ ક્યારેય અજાણી સહી-ચાવીને વિશ્વસનીય જાહેર કરવું, પ્રમાણપત્રો અવગણવા, અથવા તમે ન માંગેલું ભંડાર રૂપરેખાંકન સ્વીકારવું સમાવવું જોઈએ નહીં। જો ચાવી ખરેખર ફરી હોય, તો ડિસ્ટ્રિબ્યુશન અથવા ભંડારનો માલિક નવી ચાવી એવી ચેનલ દ્વારા પ્રકાશિત કરે છે જે તમે ચકાસી શકો, અને એ જ લાગુ કરવાની સુધારણા છે।

કઈ સીમા નિષ્ફળ ગઈ અને તેનો માલિક કોણ છે તે લખો। આગલી અપડેટ નિષ્ફળતા બીજી સીમા પર હશે, અને યાદી હોવાથી તે સુરંગ અપડેટને સુરક્ષિત બનાવે છે કે નહીં એ અંગેની બીજી બહસને બદલે પાંચ મિનિટનું નિદાન બની જાય છે।