Обновяването с apt се проваля с NO_PUBKEY след добавяне на VPN хранилище

apt източникът на вашия VPN доставчик счупи мениджъра ви на пакети, а поправката е решение, не команда. NO_PUBKEY, или оплакване, че хранилището няма файл Release, означава, че apt е отказал да се довери на този източник, така че всяка следваща операция с пакети продължава да печата същото предупреждение. Самият тунел вероятно е невинен. Отговорете на три въпроса дали все още искате този източник, и правилната поправка следва почти механично.

Първо, сложете повредата в правилната категория

Отказът на доверие назовава файла на източника и или липсващия ключ, или отсъстващия файл Release. Отказът на пренос изглежда различно: грешки в TLS сертификата, отказана връзка, изтичане на времето или прокси, което отказва CONNECT. Това разграничение решава кой текст четете, защото VPN, който прихваща TLS или блокира хоста на доставчика, дава грешки на преноса, а не грешки на подписа.

Изпълнете sudo apt update самостоятелно и прочетете края, като игнорирате кешираните попадения над него. Редът, който има значение, назовава /etc/apt/sources.list.d/ и ви казва кой файл да отворите.

Ако повредата следва вдигането на тунела, тествайте с изключен тунел и с DNS, решен през системния резолвер. Източник, който работи без VPN, е въпрос на маршрутизация или прихващане, и никакво управление на ключове няма да го поправи.

Три въпроса, които избират пътя

Все още ли инсталирате или обновявате пакети от този източник? Ако клиентът се използва активно, поправете доверието. Ако сте инсталирали клиента веднъж и сега импортирате обикновен профил в NetworkManager, източникът е мъртва тежест и премахването е честната поправка.

Второ, публикува ли доставчикът ключ и отпечатък, които можете да проверите извън канала? Трето, кой управлява ключовете на този хост: дистрибуцията или вие? Източник, подписан с ключ, който не можете да проверите, е право на обновяване, което не бива да давате.

Отговор не на първия въпрос приключва анализа. Отговор да на трите точки сочи към поправката със signed-by, която е единствената схема, която едновременно работи и остава проверима. Смесването на двата пътя, като задържите източника и го прокарате насила, е единствената опция, която си струва да изключите изрично.

Защо trusted=yes изглежда като поправка, а не е

Страницата на ръководството за sources.list е пряма за това. Задането на опцията Trusted на yes казва на apt да приеме източника дори когато не мине удостоверяване, което изключва apt-secure за това хранилище. Страницата го запазва за локален контекст, ако въобще се използва.

Това не е по-тясна версия на доверие към доставчика. То премахва въпроса кой е подписал индекса, така че всеки, който може да отговори за това име на хост, може да даде на машината ви пакети, които се инсталират като root.

Път за поправка: вземете ключа, после го закрепете

Вземете ключа от мястото, което доставчикът документира, и го разопаковайте в ключодържател, управляван от администратор, после насочете реда на хранилището към този файл, за да не може доверието да се изплъзне.

1. Прочетете неуспешния ред, за да получите ID на ключа и името на файла на източника.
2. Изтеглете ASCII-бронирания ключ на доставчика и изпълнете gpg --dearmor в /etc/apt/keyrings/vendor-name.gpg.
3. Добавете [signed-by=/etc/apt/keyrings/vendor-name.gpg] към записа във файла .list на този доставчик.
4. Изпълнете sudo apt update и потвърдете, че източникът изтегля индекс, вместо да повтаря предупреждението за подпис.

Предпочитайте /usr/share/keyrings за ключове, които идват с пакет, и /etc/apt/keyrings за ключове, които поставяте на ръка. Разделението не е козметично: то казва на следващия администратор кои ключове ще преживеят обновяване на пакет и кои се нуждаят от човек.

Проверете отпечатъка срещу публикуваната от доставчика стойност, преди да му се доверите. ID на ключ, поставен от форумен пост, е начинът, по който една машина започва да се доверява на право на обновяване, което никой не може да назове.

Път за премахване и защо грешката може да се върне

Вижте какво всъщност е записал инсталаторът, защото няколко файла могат да споменават същия доставчик и един от тях обикновено е остатъчно копие.

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

apt чете само файлове .list и .sources от тази директория, така че копие .save или .distUpgrade вече се игнорира; изтриването му все пак пречи на по-късен читател да го възстанови по случайност. Премахването на източника не деинсталира нищо и apt може после да опише инсталирания VPN пакет като локално инсталиран или вече недостъпен, което е съобщение за състоянието на пакета, а не връщане на грешката за доверие.

Повтарящият се случай е по-старо указание, което е инсталирало ключове с apt-key в глобалния доверен пръстен. Този път е отхвърлен и обновяване на версия може да остави ключа изпуснат или просто неконсултиран, което е точно причината грешка, мълчала година, да се появи в седмицата, в която обновявате. Проверете /etc/apt/trusted.gpg.d/, после преместете решението за доверие в реда на хранилището, където му е мястото. Ако доставчикът още печата инструкции за apt-key, използвайте signed-by така или иначе; това е схемата, която ръководството документира, и тя е тази, която оцелява след обновяване.