Оновлення 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; це схема, яку документує посібник, і та, що переживає оновлення.