Хранение ключей сторонних репозиториев в 22.04+

[Skif_off]

Уточнял, все ли из используемых сторонних репозиториев Ubuntu собирают пакеты для 22.04 и заметил, что некоторые как для Debian, так и для Ubuntu предлагают сохранять ключи не как обычно в /etc/apt/trusted.gpg.d, а в /usr/share/keyrings, где обычно лежали только ключи родных репозиториев Debian/Ubuntu (изкоробочные, так сказать).
Почему так вдруг?

[Morisson]

В keyrings разве не пароли хранятся? Т.н "связка ключей", пароли в зашифрованном (или нет, если пароль пустой) виде?

[Morisson]

https://wiki.gnome.org/Projects/GnomeKeyring

[Morisson]

Т.е gpg - это подписи пакетов, а keyring- это хранилище паролей, которые могут использоваться приложениями.
Могу ошибаться.

[Skif_off]

В общем, добавление ключей в /etc/apt/trusted.gpg.d с помощью "apt-key add" считается небезопасным, начиная с Debian 11 и Ubuntu 22.04 настоятельно рекомендуется избегать и apt-key использовать лишь для удаления уже добавленных ключей. (Когда вопрос возник, посмотрел первый попавшийся PPA, ключ лёг в /etc/apt/trusted.gpg.d - реформаторы, однако...)
Ключевое, видимо:

The problem is that any key you add to either of the above is completely and unconditionally trusted by apt. This means that when installing any package from any repo (including the official distro repos), apt will happily accept the package being signed by any of those trusted keys (whether the key belongs to the repository the package is coming from or not). This weakens the assurance provided by the package signing mechanism against malicous packages being injected into the official Ubuntu mirrors network.

What we want to do instead is configure apt to accept signatures from a third-party repository only on packages being installed from that repository — no cross-signing. Apt's default pinning rules give higher priority to official distro repos, which (in conjunction with proper key management) offers some protection against third-party repos replacing distro-provided packages.

Т.е. если, например, пакеты Wine из репозитория Wine, подписанные ключом Wine, внезапно окажутся в официальном репозитории Ubuntu или Debian, где по идее должны лежать лишь пакеты, подписанные в Ubuntu или Debian, то они будут проигнорированы apt? Если да, это вообще реальная ситуация?
Ну и о запрете замены любых пакетов из официального репозитория пакетами из стороннего речь ведь не идёт?

Пара ссылок:
https://askubuntu.com/questions/1286545/what-commands-exactly-should-replace-the-deprecated-apt-key
https://www.linuxuprising.com/2021/01/apt-key-is-deprecated-how-to-add.html

[AnrDaemon]

Тут такое дело…
Ключ, установленный через `apt-key add`, не привязан ни к какому конкретному репозиторию.
Т.е. в ситуации:
1. Ты установил у себя какой-то ключ, предположительно для нужного тебе репо.
2. В одном из установленных у тебя репо, не в том, для которого ты ключ устанавливал, появляется пакет, этим ключом подписанный.
3. Система с радостью ставит этот пакет, т.к. верификация прошла.

Хорошо, если это нужный пакет и он не нарушает работу системы.
А если это какая-то лажа, заменяющая системные файлы?
Если бы ключи были привязаны к конкретным репозиториям, такая ситуация как минимум вызвала бы недоумение установщика и отказ устанавливать пакет без подписи и явного подтверждения пользователем.

[F12]

посмотрел первый попавшийся PPA, ключ лёг в /etc/apt/trusted.gpg.d

- а куда же ему ложиться если не туда?..
   ... ведь пользователь принял решение: доверять этому PPA, следовательно и ключ лег в каталог предназначенный для доверенных ключей
      ... а PPA, это всегда риски, и не только в плане безопасности

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

[Skif_off]

AnrDaemon, значит, понял верно, спасибо.

(Нажмите, чтобы показать/скрыть)

Но всё равно не понял, насколько это реально Злоумышленнику придётся подломить два источника: чей-то (что-то достаточно популярное, полагаю) закрытый ключ и чей-то репозиторий, тоже не обделённый вниманием. Замысловато выходит, один как-то попроще, ведь если кто-то профукал свой ключ, то также мог и данные для доступа к репозиторию профукать.

- а куда же ему ложиться если не туда?..

Раз выпиливают небезопасное, значит, и добавление PPA должны бы доработать

К слову, по второй ссылке говорят про /usr/share/keyrings, по первой же при ручном добавлении ключей рекомендуют использовать /etc/apt/keyrings (создать с 0755, если нет) вместо /usr/share/keyrings. Судя по вики Debian, похоже, /usr/share/keyrings - только если ключ будет добавляться/обновляться deb-пакетом, т.е. автоматически.
Но, например, в инструкциях для Wine и VirtualBox стоит /usr/share/keyrings. Хотя, возможно, просто потому, что в 22.04 и старее каталога /etc/apt/keyrings нет.

[AnrDaemon]

Почитайте про FHS. Лучше поймёте разницу в назначении между разными каталогами в системе.

[Skif_off]

AnrDaemon, при чём здесь FHS? И новичку скорее всего понятно, что по-хорошему - в /etc, и вики Debian вполне определённо доносит ("SHOULD be"), по какому принципу выбирать место, не увлекаясь описанием разницы между /etc, /usr и /usr/local.

[AnrDaemon]

При всём. И, да, статья не о разнице между /etc, /opt и /usr, а про apt и PGP ключи.
Так что неудивительно, что в нюансы никто не вдаётся. Но SHOULD - это не MUST, а статья, с которой начался разговор, освещает проблему использования сторонних репозиториев, а не их настройки в системе.

[Skif_off]

Похоже, чего-то не догоняю: знакомство со стандартом иерархии ФС может привести к предположению, что для добавляемых ключей сторонних репозиториев, как и адресов и параметров оных, логичнее использовать /etc, но не обяъяснит, почему проект Wine, например, использует в инструкциях /usr/share/keyrings, хотя в документации Debian для своей apt в этом случае вполне определённо рекомендуют /etc/apt/keyrings
А так  да, в соответствии с FHS и /usr/local/etc, выходит, не будет грубой ошибкой.

P.S. Попробую сейчас тему переименовать, слишком уж общее название, это как-то не очень правильно.

[AnrDaemon]

/etc/apt/keyrings

Используется исключительно apt'ом (и другими программами, использующими его бибилиотеки).

/usr/share/keyrings

Может использоваться любим приложением в системе.

[Skif_off]

Может использоваться любим приложением в системе.

Зачем им, не связанным с управлением/верификацией пакетов, ключи подписи этих самых пакетов? Если кому-то нужно - apt, libapt или просто по известному пути заглянуть.


Залез в чат #winehq, один из пользователей из числа контрибуторов ответил:

It came from https://bugs.winehq.org/show_bug.cgi?id=52439 , but there was likely not a conscious decision to use /usr/share/keyrings rather than /etc/apt/keyrings.

Для себя решил в любом случае использовать /etc/apt/keyrings: как и /etc/apt/trusted.gpg.d, выходит тот же подкаталог /etc/apt, рядом с /etc/apt/sources.list.d, - всё красиво и логично.