これUbuntu apt-key のマニュアルページ以下の関連注意事項を含めてくださいapt-key add
。
注:このコマンドは使用しないでください。代わりに、説明を含む名前と "gpg"または "asc"をファイル拡張子として使用して、キーリングを/etc/apt/trusted.gpg.d/ディレクトリに直接配置する必要があります。
このようなアドバイスは、他の場所では見たことがないようです。独自のリポジトリをホストするほとんどのプロジェクトでは、キーファイルをダウンロードしてapt-key
。
- この提案の動機は何ですか?
- これがUbuntu主義ですか?それともAPTベースのディストリビューションに適用されますか?
ベストアンサー1
このアイテムの説明は古くなっています。私が投稿したので、これを知っています。Debian リポジトリDebian 9 APT で変更が見つかったときに指示を更新しました。実際、マニュアルのこの部分は間違ったディレクトリにあるため、もう使用されていません。
.d
これは、実際にはAPTのサイト間の脆弱性を防ぐためのディレクトリなどとは何の関係もありません。以前のシステムでは、利便性のために別々のキーリングファイルを使用していましたが、これはセキュリティのために不可欠です。あなたの安全。
これが脆弱性です。 2つのストレージパブリッシャーAとBを考えてみましょう。 Debian 8 以前では、両方のパブリッシャのキーがユーザーのコンピュータの単一のグローバルキーリングにありました。パブリッシャAがパブリッシャBのリポジトリWWWサイトを何らかの方法で交換できる場合、パブリッシャAは破壊的なパッケージを公開できます。A 自分の鍵で署名、APTは喜んでそれを受け入れてインストールします。結局、Aのキーはすべてのリポジトリでグローバルに信頼されます。
緩和策は、サイト運営者ごとに別々のキーリングを使用してください。Signed-By
、リポジトリ定義で別の設定を使用してこれらのキーリングを参照します。具体的には、パブリッシャAのキーはリポジトリAでのみ使用され、パブリッシャSigned-By
BのキーはSigned-By
リポジトリBでのみ使用されます。したがって、パブリッシャAがパブリッシャBのリポジトリを置き換えると、APTはそのパッケージとリポジトリがパブリッシャBのキーではなくパブリッシャAのキーで署名されるため、そのパッケージに含まれる破壊的なパッケージは許可されません。
現在のメカニズムは、/etc/apt/trusted.gpg.d
2005年頃から始まった貧困層の高齢者にとって多少欠陥のある中間住宅であり、これは十分ではありません。パッケージマネージャが別のファイルと同じように1つのステップでインストール(またはfetch
//を使用してダウンロード)できるように、別のファイルにキーリングを設定します。 (パッケージ管理者は、Aパブリッシャーの特別広告をブロックする役割を担います。curl
wget
これは私のストレージキーリングです。ただし、すべてのリポジトリでグローバルに信頼できるキーセットに追加されます。現在存在する完全なメカニズムは別いいえグローバルに信頼できるキーリングファイル/usr/share/keyrings/
。
私の指示はすでにそこにあります。 ☺現在、Debianの独自のリポジトリをこのメカニズムに移動して、信頼できるグローバルキーを使用しなくなるようにする措置が講じられています。あなたが見つけた「最も多くの項目」について話したいかもしれません。結局のところ、彼らは現在、あなたのコンピュータからAPTへのグローバルアクセスを彼らに渡すように指示しています。
追加読書
- ダニエル・カーン・ギルモア(2017-05-02)。 バージョン別キーを別途外部に配送してください。
/etc/apt/trusted.gpg.d/
。 Debian のバグ #861695. - ダニエル・カーン・ギルモア(2017-07-27)。 Debian
sources.list
エントリには、特定のキーを指す署名オプションが必要です。。 Debian のバグ #877012. - "source.list - アイテム"。サードパーティのストレージ接続ガイドライン。 Debian Wiki。 2018.
- source.listに追加してもセキュリティリスクが発生しないのはなぜですか?
- Debian 9、APT、および「GPG エラー: ...InRelease: 次の署名が無効です。」