Pembaruan apt gagal dengan NO_PUBKEY setelah menambahkan repositori VPN
NO_PUBKEY dan berkas Release yang hilang adalah kegagalan kepercayaan, bukan gangguan jaringan. Putuskan apakah akan menyematkan kunci vendor dengan signed-by atau menghapus sumbernya.
Sumber apt vendor VPN Anda telah merusak manajer paket, dan perbaikannya adalah keputusan, bukan perintah. NO_PUBKEY, atau keluhan bahwa repositori tidak memiliki berkas Release, berarti apt menolak memercayai sumber itu, sehingga setiap operasi paket berikutnya terus mencetak peringatan yang sama. Terowongannya sendiri mungkin tidak bersalah. Jawab tiga pertanyaan tentang apakah Anda masih menginginkan sumber itu, dan perbaikan yang benar mengikuti hampir secara mekanis.
Pertama, tempatkan kegagalan pada kategori yang tepat
Kegagalan kepercayaan menyebut berkas sumber dan entah kunci yang hilang atau berkas Release yang tidak ada. Kegagalan transportasi terlihat berbeda: galat sertifikat TLS, koneksi ditolak, waktu tunggu habis, atau proxy yang menolak CONNECT. Perbedaan itu menentukan artikel mana yang Anda baca, karena VPN yang mencegat TLS atau memblokir host vendor menghasilkan galat transportasi, bukan galat tanda tangan.
Jalankan sudo apt update sendirian dan baca bagian akhirnya, abaikan hasil yang tersimpan di atasnya. Baris yang penting menyebut /etc/apt/sources.list.d/ dan memberi tahu berkas mana yang perlu dibuka.
Jika kegagalan menyusul terangkatnya terowongan, ujilah dengan terowongan dimatikan dan dengan DNS yang diselesaikan melalui resolver sistem. Sumber yang berfungsi tanpa VPN adalah persoalan perutean atau pencegatan, dan tidak ada jumlah pengelolaan kunci yang akan memperbaikinya.
Tiga pertanyaan yang memilih jalur
Apakah Anda masih memasang atau meningkatkan paket dari sumber ini? Jika klien aktif digunakan, perbaiki kepercayaannya. Jika Anda memasang klien sekali dan sekarang mengimpor profil biasa ke NetworkManager, sumber itu beban mati dan penghapusan adalah perbaikan yang jujur.
Kedua, apakah vendor menerbitkan kunci dan sidik jari yang dapat Anda verifikasi di luar saluran? Ketiga, siapa yang mengelola kunci pada host ini: distribusi atau Anda? Sumber yang ditandatangani dengan kunci yang tidak dapat Anda verifikasi adalah wewenang pembaruan yang tidak seharusnya Anda berikan.
Jawaban tidak pada pertanyaan pertama mengakhiri analisis. Jawaban ya pada ketiga poin mengarah ke perbaikan signed-by, satu-satunya tatanan yang berfungsi sekaligus tetap dapat diaudit. Mencampur kedua jalur, dengan mempertahankan sumber dan memaksakannya, adalah satu-satunya opsi yang layak dikesampingkan secara eksplisit.
Mengapa trusted=yes tampak seperti perbaikan tetapi bukan
Halaman manual sources.list terus terang soal itu. Menyetel opsi Trusted ke yes memberi tahu apt agar menerima sumber itu bahkan ketika gagal autentikasi, yang mematikan apt-secure untuk repositori tersebut. Halaman itu menyimpannya untuk konteks lokal, jika memang dipakai.
Ini bukan versi yang lebih sempit dari memercayai vendor. Ini menghapus pertanyaan siapa yang menandatangani indeks, sehingga siapa pun yang dapat menjawab untuk nama host itu dapat memberikan paket ke mesin Anda yang terpasang sebagai root.
Jalur perbaikan: ambil kuncinya, lalu sematkan
Ambil kunci dari lokasi yang didokumentasikan vendor dan buka bungkusnya ke dalam gantungan kunci yang dikelola administrator, lalu arahkan baris repositori ke berkas itu agar kepercayaan tidak dapat bergeser.
- Baca baris yang gagal untuk mendapatkan ID kunci dan nama berkas sumber.
- Unduh kunci vendor yang berpelindung ASCII dan jalankan
gpg --dearmorke/etc/apt/keyrings/vendor-name.gpg. - Tambahkan
[signed-by=/etc/apt/keyrings/vendor-name.gpg]ke entri di berkas.listvendor itu. - Jalankan
sudo apt updatedan pastikan sumber mengambil indeks alih-alih mengulang peringatan tanda tangan.
Utamakan /usr/share/keyrings untuk kunci yang datang bersama paket dan /etc/apt/keyrings untuk kunci yang Anda tempatkan sendiri. Pemisahan itu bukan kosmetik: ia memberi tahu administrator berikutnya kunci mana yang akan bertahan dari peningkatan paket dan mana yang membutuhkan manusia.
Verifikasi sidik jari terhadap nilai yang diterbitkan vendor sebelum Anda memercayainya. ID kunci yang ditempel dari kiriman forum adalah cara sebuah mesin mulai memercayai wewenang pembaruan yang tidak dapat disebutkan siapa pun.
Jalur penghapusan, dan mengapa galat dapat kembali
Lihat apa yang sebenarnya ditulis pemasang, karena beberapa berkas dapat 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.listapt hanya membaca berkas .list dan .sources dari direktori itu, jadi salinan .save atau .distUpgrade sudah diabaikan; menghapusnya tetap mencegah pembaca berikutnya memulihkannya secara tidak sengaja. Menghapus sumber tidak menghapus pemasangan apa pun, dan apt kemudian dapat menggambarkan paket VPN terpasang sebagai terpasang secara lokal atau tidak lagi tersedia, yang merupakan pesan status paket dan bukan kembalinya galat kepercayaan.
Kasus yang berulang adalah panduan lama yang memasang kunci dengan apt-key ke dalam cincin tepercaya global. Jalur itu sudah usang, dan peningkatan rilis dapat membuat kunci terlepas atau sekadar tidak dikonsultasikan, dan itulah tepatnya mengapa galat yang diam selama setahun muncul pada pekan ketika Anda meningkatkan. Periksa /etc/apt/trusted.gpg.d/, lalu pindahkan keputusan kepercayaan ke baris repositori tempatnya seharusnya. Jika vendor masih mencetak instruksi apt-key, tetap gunakan signed-by; itulah tatanan yang didokumentasikan manual, dan yang bertahan dari peningkatan.