☰

Fedora 25アップグレード：パッケージアップデートキーがインストールされていません。何が起こっていますか？

tag-icon • tag-icon fedora upgrade dnf software-updates
Fedora 25アップグレード：パッケージアップデートキーがインストールされていません。何が起こっていますか？

Fedora 24は、Fedora 25アップデートをトリガーするこのかわいいGUIをポップアップとして表示します（gnomeソフトウェアを使用）。これ指示するFedora Workstationをアップグレードするには、GUIに記載されている手順に従ってください。よくやった！

一部のソフトウェアをインストールしようとすると、次のプロンプト/警告を見て驚きました。

$ sudo dnf upgrade
...
warning: /var/cache/dnf/updates-1d34501737ae01ab/packages/NetworkManager-openconnect-1.2.4-3.fc25.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fdb19c98: NOKEY
Importing GPG key 0xFDB19C98:
 Userid     : "Fedora 25 Primary (25) <[email protected]>"
 Fingerprint: C437 DCCD 558A 66A3 7D6F 4372 4089 D8F2 FDB1 9C98
 From       : /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-x86_64
Is this ok [y/N]:

手動で何かをインストールしてキーを受け入れないと、自動更新（通知）が自動的に失敗することを意味しますか？

答え1

実際、これは大丈夫です。私はそれが最良の方法だと思うかもしれません:-).

Fedora Workstationの自動更新通知は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。これは、インストールされているパッケージに異なる要件がある場合にプロンプ​​トを防ぐ標準的な方法です。 （Ansiblednfモジュールも同じことを行います）。

私の結論は、このヒントがdnf重要な役割を果たしていないことです。質問の状況を考えると、「警告」ヒントを削除して「これで大丈夫ですか？」と尋ねるのが最善です。 （これは〜になります最高libdnfPackageKitと同じパターンを使用するように修正されました。これはセキュリティの観点から奇妙に見えます。既存のRPMキーを無期限にアーカイブ。

編集：最新バージョンではdnfPKとPKが使用されますlibdnf。したがって、この問題を解決できなかったという言い訳ははるかに少なくなります。

他のリポジトリ（google-chrome.repoなど）は、HTTPSを介して更新されたキーのダウンロードに依存する可能性があります。これにはさまざまなセキュリティ属性があります。特に、PackageKitにキー固定とHSTS（主要HTTPSクライアントで使用）が実装される可能性は低いようです。そもそもセキュリティ属性が異なるメソッドを使用して更新されたキーをダウンロードする可能性が実装されている理由は不明です。少なくともこれはダウンロードしたキーをに保存しないと主張しているようです/var/cache/。ユーザーは、ディスク容量が必要になったときにそれらを削除したい場合があります。

関連情報