Автоматическая генерация LDFLAGS, CPPFLAGS и других из сообщений об ошибках [закрыто]

На самом деле это нормально. Я могу даже поспорить, что это лучший способ сделать это :-).

Автоматические уведомления об обновлении на рабочей станции Fedora используют PackageKit. Они не используют команду dnf .

Вы можете видеть, что pkcon успешно устанавливает пакеты (или обновляет с помощью pkcon -c 1 refresh && pkcon update (объяснение -c здесь )) . Ключ не подсказывает. Он также не устанавливает ключ в хранилище, используемое dnf ; если вы снова запустите dnf , он все равно будет предлагать принять ключ.

Это меня удивило, потому что хранилище ключей, используемое dnf, на самом деле rpm . PackageKit действует как интерфейс для rpm, но, очевидно, он не заполняет связку ключей rpm и не полагается на него для проверки.

Вы можете видеть, что PackageKit вместо этого сохраняет ключи, например, в / var / cache / PackageKit / 25 / metadata / fedora / gpgdir / . Возможно, в этом больше смысла, чем в традиционной организации.Таким образом можно узнать, какие ключи были загружены для какого репо.

В отличие от dnf, PackageKit не предлагает принять ключи от настроенного URL-адреса. (Обратите внимание, что если бы он сделал запрос на сохранение этого файла в / var / cache , строго говоря, этот файл не был бы чистым кешем, поскольку он также представлял бы конфигурацию пользователя :-) .

Отсутствие подсказок не снижает безопасность Fedora, потому что, например, /etc/yum.repos.d/fedora.repo указывает загрузить ключ из файла, который уже был установлен (пакетом fedora-release ). Запрос dnf также будет пропущен, если вы использовали сценарии с dnf -y install - это стандартный способ избежать запроса, когда установленный пакет имеет дополнительные требования. (Модуль Ansible dnf делает то же самое).

Я считаю, что эта подсказка dnf не считается важной. Учитывая сценарий в вопросе, вероятно, было бы лучше удалить подсказку, которая говорит «предупреждение» и спрашивает «Это нормально». (И было бы лучше исправить libdnf , чтобы использовать тот же шаблон, что и PackageKit. С точки зрения безопасности кажется довольно странным хранить старые ключи RPM на неопределенный срок .

РЕДАКТИРОВАТЬ: в более новых версиях и PK, и dnf теперь реализованы с использованием libdnf . Так что есть еще меньше оправданий, чтобы не исправить это :-).

Другие репозитории, такие как google-chrome.repo, могут полагаться на загрузку обновленных ключей по HTTPS.У этого есть другие свойства безопасности. В частности, кажется менее вероятным, что закрепление ключей и HSTS (используемые основными клиентами HTTPS) были реализованы для PackageKit. Мне неясно, почему вообще была реализована эта возможность, т.е.загрузка обновленных ключей методом с другими свойствами безопасности. Как минимум, это кажется аргументом в пользу того, чтобы не хранить загруженные ключи в / var / cache / , которые пользователь может пожелать очистить, когда им срочно понадобится дисковое пространство.