Aktualizacja apt kończy się niepowodzeniem z NO_PUBKEY po dodaniu repozytorium VPN

Źródło apt dostawcy VPN zepsuło menedżer pakietów, a poprawka jest decyzją, nie poleceniem. NO_PUBKEY, albo skarga, że repozytorium nie ma pliku Release, oznacza, że apt odmówił zaufania temu źródłu, więc każda późniejsza operacja na pakietach nadal wypisuje to samo ostrzeżenie. Sam tunel jest prawdopodobnie niewinny. Odpowiedz na trzy pytania, czy nadal chcesz to źródło, a prawidłowa naprawa następuje niemal mechanicznie.

Najpierw umieść błąd we właściwej kategorii

Błąd zaufania wskazuje plik źródła oraz brakujący klucz albo nieobecny plik Release. Błąd transportu wygląda inaczej: błędy certyfikatu TLS, odrzucone połączenie, przekroczenia czasu lub proxy, które odmawia CONNECT. Ta różnica decyduje, który artykuł czytasz, bo VPN przechwytujący TLS lub blokujący host dostawcy daje błędy transportu, a nie błędy podpisu.

Uruchom sudo apt update samo i przeczytaj końcówkę, ignorując wyniki z pamięci podręcznej powyżej. Ważna linia wskazuje /etc/apt/sources.list.d/ i mówi, który plik otworzyć.

Jeśli błąd pojawia się po podniesieniu tunelu, przetestuj z opuszczonym tunelem i z DNS rozwiązywanym przez resolver systemu. Źródło, które działa bez VPN, to kwestia trasowania lub przechwytywania, i żadne zarządzanie kluczami tego nie naprawi.

Trzy pytania, które wybierają ścieżkę

Czy nadal instalujesz lub aktualizujesz pakiety z tego źródła? Jeśli klient jest aktywnie używany, napraw zaufanie. Jeśli zainstalowałeś klienta raz i teraz importujesz zwykły profil do NetworkManagera, źródło jest martwym balastem, a usunięcie to uczciwa naprawa.

Po drugie, czy dostawca publikuje klucz i odcisk palca, które możesz zweryfikować poza kanałem? Po trzecie, kto zarządza kluczami na tym hoście: dystrybucja czy ty? Źródło podpisane kluczem, którego nie możesz zweryfikować, to uprawnienie do aktualizacji, którego nie powinieneś przyznawać.

Nie na pierwsze pytanie kończy analizę. Tak na wszystkie trzy punkty prowadzi do naprawy przez signed-by, jedynego układu, który zarówno działa, jak i pozostaje audytowalny. Mieszanie obu ścieżek, przez pozostawienie źródła i przepchnięcie go siłą, to jedyna opcja, którą warto wyraźnie wykluczyć.

Dlaczego trusted=yes wygląda na poprawkę, a nią nie jest

Strona podręcznika sources.list mówi o tym wprost. Ustawienie opcji Trusted na yes każe aptowi zaakceptować źródło nawet wtedy, gdy nie przejdzie uwierzytelniania, co wyłącza apt-secure dla tego repozytorium. Strona rezerwuje to dla kontekstu lokalnego, jeśli w ogóle jest używane.

To nie jest węższa wersja zaufania do dostawcy. Usuwa pytanie, kto podpisał indeks, więc każdy, kto może odpowiedzieć za tę nazwę hosta, może dać twojej maszynie pakiety instalowane jako root.

Ścieżka naprawy: pobierz klucz, potem go przypnij

Pobierz klucz z miejsca udokumentowanego przez dostawcę i rozpakuj go do pęku kluczy zarządzanego przez administratora, następnie skieruj linię repozytorium na ten plik, aby zaufanie nie mogło się przesunąć.

1. Przeczytaj linię, która zawodzi, aby uzyskać ID klucza i nazwę pliku źródła.
2. Pobierz klucz dostawcy opakowany w ASCII i uruchom gpg --dearmor do /etc/apt/keyrings/vendor-name.gpg.
3. Dodaj [signed-by=/etc/apt/keyrings/vendor-name.gpg] do wpisu w pliku .list tego dostawcy.
4. Uruchom sudo apt update i potwierdź, że źródło pobiera indeks, a nie powtarza ostrzeżenie o podpisie.

Preferuj /usr/share/keyrings dla kluczy, które przychodzą z pakietem, i /etc/apt/keyrings dla kluczy umieszczanych ręcznie. Ten podział nie jest kosmetyczny: mówi następnemu administratorowi, które klucze przetrwają aktualizację pakietu, a które wymagają człowieka.

Zweryfikuj odcisk palca wobec opublikowanej wartości dostawcy, zanim mu zaufasz. ID klucza wklejone z posta na forum to sposób, w jaki maszyna zaczyna ufać uprawnieniu do aktualizacji, którego nikt nie potrafi nazwać.

Ścieżka usunięcia i dlaczego błąd może wrócić

Zobacz, co instalator naprawdę zapisał, bo kilka plików może wymieniać tego samego dostawcę i jeden z nich jest zwykle pozostałą kopią.

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

apt czyta z tego katalogu tylko pliki .list i .sources, więc kopia .save lub .distUpgrade jest już ignorowana; usunięcie jej i tak nie pozwoli późniejszemu czytelnikowi przypadkiem jej przywrócić. Usunięcie źródła niczego nie odinstalowuje, a apt może potem opisać zainstalowany pakiet VPN jako zainstalowany lokalnie lub niedostępny, co jest komunikatem o stanie pakietu, a nie powrotem błędu zaufania.

Powtarzający się przypadek to starsze wskazówki, które instalowały klucze przez apt-key do globalnego pierścienia zaufania. Ta ścieżka jest przestarzała, a aktualizacja wydania może zostawić klucz porzucony lub po prostu nieużywany, i dokładnie dlatego błąd, który milczał rok, pojawia się w tygodniu twojej aktualizacji. Sprawdź /etc/apt/trusted.gpg.d/, a potem przenieś decyzję o zaufaniu do linii repozytorium, gdzie należy. Jeśli dostawca nadal drukuje instrukcje apt-key, i tak użyj signed-by; to układ, który dokumentuje podręcznik, i ten, który przetrwa aktualizację.