Kemas kini apt gagal dengan NO_PUBKEY selepas menambah repositori VPN

Sumber apt vendor VPN anda telah merosakkan pengurus pakej anda, dan pembaikannya ialah keputusan, bukan arahan. NO_PUBKEY, atau aduan bahawa repositori itu tiada fail Release, bermakna apt enggan mempercayai sumber itu, jadi setiap operasi pakej selepasnya terus mencetak amaran yang sama. Terowong itu sendiri mungkin tidak bersalah. Jawab tiga soalan tentang sama ada anda masih mahu sumber itu, dan pembaikan yang betul menyusul hampir secara mekanikal.

Pertama, letakkan kegagalan itu dalam kategori yang betul

Kegagalan kepercayaan menamakan fail sumber dan sama ada kunci yang hilang atau fail Release yang tiada. Kegagalan pengangkutan kelihatan berbeza: ralat sijil TLS, sambungan ditolak, tamat masa, atau proksi yang menolak CONNECT. Perbezaan itu menentukan artikel mana yang anda baca, kerana VPN yang memintas TLS atau menyekat hos vendor menghasilkan ralat pengangkutan, bukan ralat tandatangan.

Jalankan sudo apt update bersendirian dan baca hujungnya, sambil mengabaikan hasil cache di atasnya. Baris yang penting menamakan /etc/apt/sources.list.d/ dan memberitahu fail mana yang perlu dibuka.

Jika kegagalan berlaku selepas terowong naik, uji dengan terowong diturunkan dan dengan DNS diselesaikan melalui penyelesai sistem. Sumber yang berfungsi tanpa VPN ialah persoalan penghalaan atau pemintasan, dan tiada jumlah pengurusan kunci akan membaikinya.

Tiga soalan yang memilih laluan

Adakah anda masih memasang atau menaik taraf pakej daripada sumber ini? Jika klien digunakan secara aktif, baiki kepercayaan itu. Jika anda memasang klien sekali dan kini mengimport profil biasa ke dalam NetworkManager, sumber itu beban mati dan pembuangan ialah pembaikan yang jujur.

Kedua, adakah vendor menerbitkan kunci dan cap jari yang boleh anda sahkan di luar saluran? Ketiga, siapa mengurus kunci pada hos ini: distribusi atau anda? Sumber yang ditandatangani dengan kunci yang tidak dapat anda sahkan ialah kuasa kemas kini yang tidak sepatutnya anda berikan.

Jawapan tidak pada soalan pertama menamatkan analisis. Jawapan ya pada ketiga-tiga perkara membawa kepada pembaikan signed-by, satu-satunya susunan yang berfungsi dan kekal boleh diaudit. Mencampurkan kedua-dua laluan, dengan mengekalkan sumber dan memaksanya, ialah satu-satunya pilihan yang wajar dikecualikan secara eksplisit.

Mengapa trusted=yes kelihatan seperti pembaikan tetapi bukan

Halaman manual sources.list jelas tentangnya. Menetapkan pilihan Trusted kepada yes memberitahu apt menerima sumber itu walaupun gagal pengesahan, yang mematikan apt-secure untuk repositori tersebut. Halaman itu menyimpannya untuk konteks setempat, jika digunakan langsung.

Ini bukan versi yang lebih sempit untuk mempercayai vendor. Ia membuang persoalan siapa yang menandatangani indeks, jadi sesiapa yang boleh menjawab bagi nama hos itu boleh memberikan pakej yang dipasang sebagai root kepada mesin anda.

Laluan pembaikan: ambil kunci itu, kemudian sematkannya

Ambil kunci dari lokasi yang didokumenkan oleh vendor dan bongkar ia ke dalam gelang kunci yang diuruskan oleh pentadbir, kemudian halakan baris repositori kepada fail itu supaya kepercayaan tidak boleh hanyut.

1. Baca baris yang gagal untuk mendapatkan ID kunci dan nama fail sumber.
2. Muat turun kunci vendor yang berperisai ASCII dan jalankan gpg --dearmor ke /etc/apt/keyrings/vendor-name.gpg.
3. Tambahkan [signed-by=/etc/apt/keyrings/vendor-name.gpg] pada entri dalam fail .list vendor itu.
4. Jalankan sudo apt update dan pastikan sumber itu mengambil indeks dan bukan mengulangi amaran tandatangan.

Utamakan /usr/share/keyrings untuk kunci yang datang bersama pakej dan /etc/apt/keyrings untuk kunci yang anda letakkan sendiri. Pemisahan itu bukan kosmetik: ia memberitahu pentadbir seterusnya kunci mana yang akan bertahan selepas naik taraf pakej dan mana yang memerlukan manusia.

Sahkan cap jari terhadap nilai yang diterbitkan vendor sebelum anda mempercayainya. ID kunci yang ditampal daripada kiriman forum ialah cara sebuah mesin mula mempercayai kuasa kemas kini yang tiada siapa dapat menamakannya.

Laluan pembuangan, dan mengapa ralat itu boleh kembali

Lihat apa yang sebenarnya ditulis oleh pemasang, kerana beberapa fail boleh menyebut vendor yang sama dan salah satunya biasanya salinan yang tertinggal.

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt hanya membaca fail .list dan .sources daripada direktori itu, jadi salinan .save atau .distUpgrade sudah diabaikan; memadamnya tetap menghalang pembaca kemudian daripada memulihkannya secara tidak sengaja. Membuang sumber tidak menyahpasang apa-apa, dan apt kemudian boleh menerangkan pakej VPN yang dipasang sebagai dipasang secara tempatan atau tidak lagi tersedia, yang merupakan mesej status pakej dan bukan kembalinya ralat kepercayaan.

Kes yang berulang ialah panduan lama yang memasang kunci dengan apt-key ke dalam gelang kepercayaan global. Laluan itu sudah usang, dan naik taraf keluaran boleh membiarkan kunci itu tercicir atau sekadar tidak dirujuk, dan itulah sebabnya ralat yang senyap selama setahun muncul pada minggu anda menaik taraf. Semak /etc/apt/trusted.gpg.d/, kemudian pindahkan keputusan kepercayaan ke dalam baris repositori di tempatnya. Jika vendor masih mencetak arahan apt-key, gunakan juga signed-by; itulah susunan yang didokumenkan oleh manual, dan yang bertahan selepas naik taraf.