HTTPS dan VPN tidak mengesahkan pakej yang anda pasang

Satu kemas kini gagal, dan cadangan dalam urutan mengikut pola biasa: trafik melalui VPN, jadi muat turun mesti boleh dipercayai, dan pemeriksaan tandatangan dilonggarkan untuk melepasi ralat itu. Dua idea berasingan telah dileburkan menjadi satu ayat. Penyulitan melindungi laluan antara dua hujung; pengesahan menentukan sama ada bait itu datang daripada penerbit yang anda maksudkan. Terowong menyediakan yang pertama dan tidak berkata apa-apa tentang yang kedua.

Gejala biasanya ralat pengesahan pada satu hos, dalam satu repositori, sementara semua yang lain dikemas kini seperti biasa. Bentuk itu sudah memberitahu anda laluan rangkaian berfungsi dan perselisihannya ialah tentang kepercayaan.

Dua kawalan yang menjawab soalan berbeza

Keselamatan pengangkutan menjawab siapa yang berada di hujung sambungan ini dan sama ada seseorang di laluan itu boleh membacanya atau mengubahnya. Pengesahan pakej menjawab sama ada artifak ini diterbitkan oleh pihak berkuasa yang anda konfigurasikan, dan ia mesti bertahan apabila dimuat turun melalui cermin yang tidak anda kawal.

Soalan-soalan itu hanya bertindih di tepinya. Sijil yang betul pada cermin membuktikan cermin itu ialah cermin; ia tidak membuktikan cermin itu menyimpan kandungan penerbit yang tidak diubah. Pakej bertandatangan membuktikan penerbit menandatanganinya; ia tidak memberitahu anda rangkaian menyampaikan versi terbaharu atau repositori yang anda tunjukkan ialah yang diluluskan organisasi anda.

Mod kegagalan yang orang cipta dengan mematikan pemeriksaan ialah kehilangan kekal jaminan kedua, sebagai pertukaran untuk satu muat turun yang berjaya. Pertukaran itu tidak kelihatan sehingga hari ia penting.

Apa yang sebenarnya disahkan apt

Model APT ialah rantaian arkib yang disahkan. Metadata keluaran bertandatangan membawa melalui checksum kepada indeks pakej, dan indeks itu membawa melalui checksum kepada fail pakej individu. Pengesahan rantaian itulah yang menjadikan cermin tidak dipercayai tetapi boleh digunakan: cermin boleh menyajikan apa sahaja, dan tandatangan metadata menentukan sama ada APT menerimanya.

Ini sengaja bukan sama seperti memeriksa tandatangan penyelenggara pada setiap pakej yang dipasang, dan perbezaan itu menjelaskan mengapa «pakej itu bertandatangan» dan «arkib itu disahkan» digunakan secara bertukar ganti dalam laporan pepijat sedangkan maksudnya berbeza.

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

Baca keluaran kemas kini, bukan hanya kod keluar. APT menamakan repositori yang metadatanya gagal, dan nama itu ialah sempadan yang perlu disiasat. Repositori yang ditanda sebagai dipercayai tanpa pengesahan tandatangan, atau penggantian untuk repositori tidak selamat, ialah keputusan konfigurasi yang dibuat oleh seseorang dan dia sepatutnya boleh menjelaskannya.

Kesegaran ialah sifat berasingan yang lain. Fail metadata bertandatangan sah boleh menjadi lebih lama daripada yang anda lihat minggu lalu, sebab itu metadata keluaran membawa tarikh luput dan sebab itu masalah jam pada klien boleh menghasilkan ralat pengesahan yang kelihatan seperti masalah kunci.

Apa yang dnf5 periksa secara berasingan

Bahagian RPM menawarkan dua suis berbeza, dan mengelirukannya menghasilkan kelas kesilapan yang sama ke arah bertentangan. Satu mengawal sama ada fail pakej mesti membawa tandatangan sah; satu lagi mengawal sama ada metadata repositori mesti bertandatangan. Kedua-duanya boleh ditetapkan secara bebas, dan sistem boleh menjadi ketat pada satu dan longgar pada yang lain.

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

Pertanyaan pakej menunjukkan rupa metadata tandatangan salinan yang dipasang, yang merupakan pemeriksaan realiti berguna terhadap fail konfigurasi yang mendakwa ketegasan. Apa yang tidak diberitahunya ialah dasar sokongan distribusi, dan itulah yang patut anda ikuti dan bukannya arahan umum «aktifkan GPG» daripada forum.

Di mana kedua-dua pengurus berbeza, perbezaannya bersifat seni bina dan bukan tanda salah satu lebih lemah. Kedua-duanya mengesahkan kandungan penerbit; mereka meletakkan tandatangan pada titik berbeza dalam rantaian.

Apa yang ditambah oleh terowong dan apa yang tidak

VPN boleh menyediakan laluan yang diperlukan, menjauhkan trafik kemas kini daripada rangkaian akses yang tidak dipercayai dan mengurangkan apa yang dilihat pemerhati setempat. Itu faedah operasi sebenar, dan tiada satu pun daripadanya ialah pengesahan penerbit.

HTTPS menambah jaminannya sendiri, dan jaminan itu lebih sempit daripada yang dirasakan. Ia mengesahkan hujung TLS yang anda sambungkan. Jika hujung itu ialah cermin, anda telah mengesahkan cermin itu, bukan kandungan arkib yang disajikannya. Inilah tepatnya kes yang wujudnya rantaian metadata bertandatangan.

Tiada satu pun kawalan itu menjanjikan ketersediaan. Rangkaian boleh menolak penghantaran, dan objek yang disahkan tidak semestinya yang terbaharu. Gunakan dasar kesegaran pengurus pakej itu sendiri dan bukannya membuat kesimpulan daripada kehadiran ikon mangga.

Diagnosis sempadan yang gagal

Namakan peringkat sebelum mengubah apa-apa: penyelesaian DNS, proksi atau laluan, identiti hujung TLS, pengesahan arkib, pemeriksaan tandatangan pakej, atau pemasangan. Setiap satu mempunyai bentuk ralat dan pemilik yang berbeza.

Membaiki laluan rangkaian tidak sepatutnya sekali-kali melibatkan pengisytiharan kunci tandatangan yang tidak dikenali sebagai dipercayai, mengabaikan sijil, atau menerima konfigurasi repositori yang anda tidak minta. Jika kunci benar-benar diputar, distribusi atau pemilik repositori menerbitkan kunci baharu melalui saluran yang anda boleh sahkan, dan itulah pembetulan yang perlu digunakan.

Tuliskan sempadan mana yang gagal dan siapa pemiliknya. Kegagalan kemas kini seterusnya akan berlaku pada sempadan lain, dan mempunyai senarai itu menjadikannya diagnosis lima minit dan bukannya perdebatan lain tentang sama ada terowong menjadikan kemas kini selamat.