apt-keyのUbuntuのマニュアルページには、次の注意事項が記載されていますapt-key add。

注：このコマンドを使用する代わりに、キーリングを/etc/apt/trusted.gpg.d/ディレクトリに直接配置し、説明的な名前とファイル拡張子として「gpg」または「asc」を指定する必要があります。

このアドバイスを他のどこかで見たことがないと思います。独自のリポジトリをホストするほとんどのプロジェクトでは、キーファイルをダウンロードしてで追加するように言われていますapt-key。

1. このアドバイスの背後にある動機は何ですか？
2. これはUbuntu-ismですか、それともAPTベースのディストリビューションに適用されますか？

それらのプロジェクトは古い指示を持っています。私がこれを知っているのは、Debianリポジトリを公​​開していて、Debian 9 APTの変更について知ったときに説明を更新したからです。実際、マニュアルのこの部分は、間違ったディレクトリであるため、現在は古くなっています。

これは実際には.dディレクトリに関するものではなく、APTのクロスサイト脆弱性の防止に関するものです。古いシステムでは、便宜上、別々のキーリングファイルを使用していましたが、これは現在、セキュリティのために必要です。あなたのセキュリティ。

これは脆弱性です。2つのリポジトリパブリッシャーAとBについて考えてみます。Debian8以前の世界では、両方のパブリッシャーのキーは、ユーザーのマシンの単一のグローバルキーリングに入っていました。パブリッシャーAがパブリッシャーBのリポジトリWWWサイトに取って代わるように手配できた場合、AはA自身のキーで署名された破壊的なパッケージを公開でき、APTは喜んで受け入れてインストールします。結局のところ、Aのキーは、すべてのリポジトリに対してグローバルに信頼されています。

緩和策は、ユーザーが個々の発行元に個別のキーリングを使用し、それらのキーリングをSigned-Byリポジトリ定義の個別の設定で参照することです。具体的には、パブリッシャーAのキーはSigned-ByリポジトリA のでのみ使用され、パブリッシャーBのキーはSigned-ByリポジトリB のでのみ使用されます。このように、パブリッシャーAがパブリッシャーBのリポジトリに取って代わった場合、APTはそれらから破壊的なパッケージを受け入れません。リポジトリは、発行元Bではなく発行元Aの鍵によって署名されています。

/etc/apt/trusted.gpg.d手元のメカニズムはかなり良い十分ではありません2005年かそこらで背中から、この方の古い貧乏人のやや不備途中の家です。別のファイルにキーリングを設定するので、パッケージマネージャーでパッケージ化し、他のファイルと同じように、パッケージマネージャーによって1ステップでインストール（またはfetch/ curl/でダウンロードwget）できます。（パッケージマネージャーは、パブリッシャーAの特別なthis-is-my-repository-keyringパッケージがパブリッシャーBに上書きインストールされるのを防ぎます。通常の方法では、パッケージ間のファイルの競合を処理します。）ただし、キーのセットに追加します。これは、すべてのリポジトリでグローバルに信頼されています。現在存在する完全なメカニズムは、グローバルに信頼されていない個別のキーリングファイルを使用し/usr/share/keyrings/ます。

私の指示はすでにそこにあります。Debian Debianのリポジトリをこのメカニズムに移動する動きがあり、グローバルに信頼された鍵も使用されなくなりました。あなたが見つけたそれらの「ほとんどのプロジェクト」で言葉を持​​ちたいかもしれません。結局のところ、彼らは現在、あなたのマシン上のAPTへのグローバルアクセスを彼らに引き渡すようにあなたに指示しています。

参考文献

• ダニエル・カーン・ギルモア（2017-05-02）。 リリース固有のキーは、の外で個別に発送してください/etc/apt/trusted.gpg.d/。Debianバグ＃861695。
• ダニエル・カーン・ギルモア（2017-07-27）。 debian sources.listエントリには、特定のキーを指す署名付きオプションが必要です。Debianバグ＃877012。
• "Sources.listエントリ"。サードパーティのリポジトリに接続する手順。Debian wiki。2018。
• sources.listに追加することがセキュリティリスクにならないのはなぜですか？
• Debian 9、APT、および「GPGエラー：... InRelease：次の署名は無効です：」

apt-key delは、keyidキーの意味のないハッシュです。

ファイル名のような意味のある名前を使ってキーをアンインストールできれば、より簡単です。

JdeBPが言うように、これはdebianパッケージの一部としてインストールされる信頼できる鍵ファイルでうまく機能します。キーファイルを手動でインストールした場合も、より良い方法だと思います。

現在「初期テスト」中の新しいメカニズムでは、これはさらに単純化されています。削除/無効にする必要があるのは、リポジトリ（sources.list / sources.list.d内）のみです。これにより、そのリポジトリに設定されたキーの許可が自動的に停止します（別のリポジトリでも使用されている場合を除く）。

セキュリティの新しいメカニズムを利用する方法がわかりません。私は彼らのパッケージを使用する場合、私は誰かを信頼する必要があると思います。パッケージインストールプロセスはまだroot:-) として実行されています。