Страница людей Ubuntu для меткого ключа включает в себя следующее примечание относительно apt-key add:

Примечание. Вместо использования этой команды брелок следует поместить непосредственно в каталог /etc/apt/trusted.gpg.d/ с описательным именем и либо "gpg", либо "asc" в качестве расширения файла.

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

1. Какова мотивация этого совета?
2. Это Ubuntu-изм или он применим к любому дистрибутиву на базе APT?

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

На самом деле это не связано с .dкаталогами, а связано с предотвращением межсайтовой уязвимости в APT. В старой системе для удобства использовались отдельные файлы ключей, но теперь это необходимо для безопасности; ваша безопасность.

Это уязвимость. Рассмотрим двух издателей репозитория, A и B. В мире Debian 8 и ранее ключи обоих издателей помещались в единый глобальный набор ключей на компьютерах пользователей. Если издатель А может каким-то образом договориться о замене WWW-сайта репозитория издателя Б, то А может публиковать подрывные пакеты, подписанные собственным ключом А , которые APT с радостью примет и установит. В конце концов, ключу A доверяют во всем мире для всех хранилищ.

Меры предосторожности предназначены для пользователей, чтобы использовать отдельные наборы ключей для отдельных издателей и ссылаться на эти наборы ключей с индивидуальными Signed-Byнастройками в своих определениях репозитория. В частности, ключ издателя A используется только в Signed-Byхранилище A, а ключ издателя B используется только в Signed-Byхранилище B. Таким образом, если издатель A вытесняет хранилище издателя B, APT не будет принимать подрывные пакеты из него, поскольку они и хранилище подписано ключом издателя А, а не издателем Б.

/etc/apt/trusted.gpg.dМеханизм под рукой старший бедняка несколько испорчен полпути к этому, со спины в 2005 году или около того , что не достаточно хорош. Он устанавливает связку ключей в отдельном файле, так что он может быть упакован и просто установлен за один шаг менеджером пакетов (или загружен с fetch/ curl/ wget), как любой другой файл. (Менеджер пакетов предотвращает установку специального пакета this-is-my-repository-keyring издателя A обычным способом, который он обрабатывает конфликты файлов между пакетами в целом.) Но он все равно добавляет его в набор ключей. это глобально доверено для всех репозиториев. Полный механизм, который существует в настоящее время, использует отдельные, не глобально доверенные, файлы ключей в /usr/share/keyrings/.

Мои инструкции уже есть. Fo Есть шаги, чтобы переместить собственные репозитории Debian в этот механизм, чтобы они также больше не использовали ключи, которым доверяют глобально. Возможно, вы захотите поговорить с теми «большинством проектов», которые вы нашли. В конце концов, они в настоящее время инструктируют вас передать им глобальный доступ к APT на вашей машине.

дальнейшее чтение

• Даниэль Кан Гиллмор (2017-05-02). Пожалуйста, отправляйте ключи, специфичные для релиза, отдельно от/etc/apt/trusted.gpg.d/ . Ошибка Debian # 861695.
• Даниэль Кан Гиллмор (2017-07-27). Записи Debian sources.listдолжны иметь подписанные опции, указывающие на определенные ключи . Ошибка Debian # 877012.
• Msgstr "Запись Sources.list" . Инструкция по подключению к стороннему репозиторию . Debian Wiki 2018.
• Почему нельзя добавить угрозу в список sources.list?
• Debian 9, APT и «Ошибка GPG: ... InRelease: недопустимы следующие подписи:»

apt-key delберет keyid, который является бессмысленным хешем ключа.

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

Как говорит JdeBP, это прекрасно работает с файлами доверенных ключей, которые устанавливаются как часть пакета debian. Я думаю, что это может быть лучше, когда вы вручную установили файл ключа.

В новом механизме, который в настоящее время находится в «первоначальном тестировании», это еще больше упрощается. Вам нужно только удалить / отключить одну вещь: хранилище (в sources.list / sources.list.d). Это автоматически прекратит использование ключа, настроенного для этого репо (если только он не использовался другим репо).

Я не знаю, как воспользоваться новым механизмом безопасности. Я просто предполагаю, что мне нужно кому-то доверять, если я использую их пакет. Процесс установки пакета все еще выполняется как root:-).