Acquire::http::Proxy の設定が機能していても、どのプログラムが鍵を取得しているかを知るまでは、署名鍵のダウンロード失敗について多くは証明しません。

apt-key adv を使う古い手順は GnuPG の鍵サーバー経路を通ります。他の設定方法では curl やブラウザーで鍵をダウンロードします。これらのプログラムはすべてが APT 自身のプロキシ設定を読むわけではありません。

GnuPG の鍵サーバー要求の場合

GnuPG は該当するネットワーク操作に dirmngr を使います。文書化されたオプションには honor-http-proxy と明示的な http-proxy 設定があり、明示的な設定は環境変数を上書きします。実際に使われる GnuPG のホームとアカウント、とくに特権コマンドの場合はそれを確認してください。

鍵サーバーの URL も確認してください。ネイティブな鍵サーバー接続は、同じ鍵に対する HTTPS 要求とは同じではありません。HTTP プロキシ経由のブラウザーアクセスは、鍵サーバーのポートへの別個の直接接続の許可を確立しません。

発行者が示す現在のインストール方法に従う

ネットワークアクセスを直すために廃止されたグローバル信頼コマンドを復活させないでください。発行者の現在の手順は鍵の取得元と想定されたキーリングを示すはずです。HTTPS ダウンロードを使う場合は、その要求を行う HTTP クライアントを設定してください。発行者が公開されて到達可能で、公開の中間者が許可されている場合、HTTP プロキシ一覧は候補のエンドポイントを提供します。フィンガープリントの検証は別の要件として残ります。

発行者の情報を通じて鍵の完全な期待フィンガープリントを確認してください。ダウンロードしたファイル、一致する表示名、検索結果は身元を確立しません。鍵のローテーションでは、現在文書化されている交換手順を使ってください。

APT の Signed-By オプションは、ソース間で一般的な信頼を与える代わりに、そのリポジトリを特定のキーリングに対応付けられます。必要なキーリングの形式と拡張子を確認し、取得アカウントがファイルを読めて親ディレクトリをたどれることを確かめてください。管理者アクセスだけではその許可を確立しません。

エラーに次の確認を指し示させる

  • タイムアウトはダウンローダーの経路かエンドポイントへの到達性に関わります。
  • プロキシの要求はそのアカウントと対応方式に関わります。
  • フィンガープリントの不一致は配送後の信頼の失敗です。
  • 後続の APT 署名エラーはキーリングの経路かリポジトリの関連付けに関わることがあります。

署名検証を保ったままその段階を解決してください。無効にすると、署名鍵の設定が提供すべき検査が失われます。

関連記事