apt-keyのUbuntumanページには、apt-key addに関する次の注意事項が含まれています。 ：
注：このコマンドを使用する代わりに、キーリングを
/etc/apt/trusted.gpg.d/ディレクトリに直接配置する必要があります。
説明的な名前と「gpg」または「asc」のいずれかをファイルとして使用します。拡張機能。
このアドバイスは他では見たことがないと思います。独自のリポジトリをホストするほとんどのプロジェクトは、キーファイルをダウンロードし、apt-keyで追加すると言います。 。
- このアドバイスの背後にある動機は何ですか？
- これはUbuntu主義ですか、それとも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の
/etc/apt/trusted.gpg.d 手元にあるメカニズムは、2005年頃からの、これに向けた古い貧乏人のやや欠陥のある中途半端な家であり、それは十分ではありません。キーリングを別のファイルに設定するため、パッケージマネージャーでパッケージ化してワンステップでインストールできます（またはfetchでダウンロードできます）。 / curl / wget ）他のファイルと同じように。 （パッケージマネージャーは、パブリッシャーAの特別な this-is-my-repository-keyringの防止を処理します パッケージは、一般にパッケージ間のファイルの競合を処理する通常の方法で、パブリッシャーBにインストールされます。）ただし、すべてのリポジトリでグローバルに信頼されているキーのセットに追加されます。現在存在する完全なメカニズムは、個別に使用しますが、 /usr/share/keyrings/にあるグローバルに信頼されたキーリングファイル 。
私の指示はすでにそこにあります。 ☺Debian自身のリポジトリをこのメカニズムに移行する動きが進んでいるため、グローバルに信頼されているキーも使用されなくなりました。あなたが見つけたそれらの「ほとんどのプロジェクト」について一言伝えたいと思うかもしれません。結局のところ、彼らは現在、あなたのマシン上のAPTへのグローバルアクセスを彼らに引き渡すようにあなたに指示しています。
関連：Slack – Slackでスレッドを開始するためのショートカットまたはコマンド？さらに読む
- ダニエルカーンギルモア（2017-05-02）。 リリース固有のキーは
/etc/apt/trusted.gpg.d/の外部に個別に発送してください 。 Debianバグ＃861695。 - ダニエルカーンギルモア（2017-07-27）。 Debian
sources.listエントリには、特定のキーを指すサインバイオプションが必要です 。 Debianバグ＃877012。 - 「Sources.listエントリ」。 サードパーティのリポジトリに接続するための手順 。 Debianwiki。 2018年。
- sources.listに追加するのはセキュリティリスクではないのはなぜですか？
- Debian 9、APT、および「GPGエラー：…InRelease：次の署名が無効でした：」