Сторінка Ubuntu man для apt-ключа містить таке примітку щодо apt-key add:

Примітка. Замість використання цієї команди брелок слід розміщувати безпосередньо в каталозі /etc/apt/trusted.gpg.d/ з описовим іменем та "gpg" або "asc" як розширення файлу.

Я не думаю, що я жодного разу ще не бачив цієї поради. Більшість проектів, які розміщують власні сховища, кажуть завантажити свій ключовий файл та додати його apt-key.

1. Яка мотивація за цією порадою?
2. Це Ubuntu-ism, чи він застосовується до будь-якого дистрибутива на основі APT?

Ці проекти мають застарілі інструкції. Я це знаю, оскільки публікую сховище Debian і оновив свої інструкції, коли дізнався про зміни в Debian 9 APT. Дійсно, ця частина посібника зараз застаріла, оскільки це неправильний каталог.

Це насправді не стосується .dкаталогів, а більше - запобігання вразливості між сайтами в APT. Старіша система використовувала окремі файли брелоків для зручності, але тепер це є необхідним для безпеки; ваша безпека.

Це вразливість. Розглянемо двох видавців репозиторіїв, A і B. У світі Debian 8 і раніше, обидва ключі видавців перейшли в єдиний глобальний брелок на машинах користувачів. Якби видавець A міг якось домовитись про витіснення веб-сайту сховища WWW видавця B, тоді A міг би публікувати підривні пакети, підписані власним ключем A , які APT з радістю прийме та встановить. Зрештою, ключ A довіряється глобально для всіх сховищ.

Пом'якшення наслідків полягає в тому, що користувачі можуть використовувати окремі брелоки для брелоків для окремих видавців та посилатися на ці брелоки з окремими Signed-Byналаштуваннями у своїх визначеннях сховища. Зокрема, ключ видавця A використовується лише у Signed-Byсховищі A, а ключ видавця B використовується лише у Signed-Byсховищі B. Таким чином, якщо видавець A замінить сховище видавця B, APT не прийме з нього підривні пакети, оскільки вони та сховище підписується ключем видавця A, а не видавцем B.

/etc/apt/trusted.gpg.dМеханізм під рукою старший бідняка дещо зіпсований півдорозі до цього, зі спини в 2005 році або близько того , що не достатньо хороший. Він встановлює брелок для ключів в окремий файл, щоб його можна було упакувати і просто встановити за один крок менеджером пакунків (або завантажити з fetch/ curl/ wget), як і будь-який інший файл. (Менеджер пакунків обробляє, не дозволяючи видавцеві спеціального пакета ключів-цього-мого репозиторію від встановлення над видавцем B, як звичайно, він обробляє файлові конфлікти між пакунками загалом.) Але він все ще додає його до набору ключів що є глобальним довірою для всіх сховищ. Повний механізм, який існує зараз, використовує окремі файли брелоків , що не довіряються глобальній програмі /usr/share/keyrings/.

Мої вказівки вже є. ☺ Існують рухи вперед для переміщення власних сховищ Debian до цього механізму, так що вони також більше не використовують глобально надійні ключі. Можливо, ви хочете поговорити з тими "більшість проектів", які ви знайшли. Зрештою, вони зараз доручають вам передавати їм глобальний доступ до APT на вашій машині.

Подальше читання

• Даніель Кан Гілмор (2017-05-02). Будь ласка завантажуйте знімачі конкретного окремо за межами/etc/apt/trusted.gpg.d/ . Помилка Debian # 861695.
• Даніель Кан Гілмор (2017-07-27). Записи debian sources.listповинні мати параметри входу, що вказують на конкретні клавіші . Помилка Debian # 877012.
• "Запис Sources.list" . Інструкції щодо підключення до стороннього сховища . Вікі Debian. 2018 рік.
• Чому до ризику безпеки не додати джерела?
• Debian 9, APT та "GPG error: ... InRelease: Наступні підписи були недійсними:"

apt-key delприймає той keyid, що є безглуздим хешем ключа.

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

Як каже JdeBP, це чудово працює з надійними ключами файлів, які встановлені як частина пакета debian. Я думаю, що також може бути приємніше, коли ви вручну встановили файл ключа.

У новому механізмі, який зараз перебуває на "початковому тестуванні", це ще більше спрощується. Вам потрібно видалити / вимкнути лише одне: сховище (в source.list / source.list.d). Це автоматично припинить дозволу ключа, налаштованого для цього репо (якщо він також не використовувався іншим репо).

Я не знаю, як скористатися новим механізмом безпеки. Я просто припускаю, що мені потрібно довіряти комусь, якщо я буду використовувати їхній пакет. Процес встановлення пакета все ще працює як root:-).