テクノロジー · 実用ガイド
APT の NO_PUBKEY：リポジトリを確認し、Signed-By で鍵設定を修復する
有効なソースを特定し、公開者と完全なフィンガープリントを照合。鍵の形式、_apt の読み取り権限、Signed-By を確認して、同じリポジトリの署名検証が復旧したか確かめる。
APT の NO_PUBKEY は、そのソースの設定でリポジトリのメタデータを署名した鍵を利用できないことを示す。掲示板や鍵サーバーで見つけた鍵が正しいという意味ではなく、署名検証を無効にする理由にもならない。
安全な修復はリポジトリごとに行う。エラーを保存してソースを特定し、公開者の公式経路で運営者と完全なフィンガープリントを確認する。正しい形式の専用鍵リングを Signed-By で指定し、認証を回避するオプションなしで同じ更新をやり直す。
1. 信頼設定を変える前にエラーを保存
通常の更新を再実行して出力全体を保存する。NO_PUBKEY の識別子、リポジトリ URL、suite またはコード名、InRelease と Release.gpg のどちらが示されたかを記録する。この段階では鍵を追加しない。複数の第三者ソースが別々の警告を出す場合があるため、表示順ではなくホスト名と suite で対象を判断する。
/etc/apt/sources.list と /etc/apt/sources.list.d 内で認識される .list、.sources を調べる。該当する行または deb822 スタンザを、URIs、Suites、Signed-By、Enabled を含めて読む。コメント化された .list 行や Enabled: no のスタンザは無効で、別の拡張子のバックアップも有効なソースではない。エラーの URL と suite に一致する有効な重複項目をすべて記録する。再帰検索は手がかりであり、APT が読み込んだ証拠ではない。
2. 公式アーカイブと第三者リポジトリを区別
Debian、Ubuntu の標準インストールには、ディストリビューションが管理する鍵リングパッケージを通じて公式アーカイブの鍵が含まれる。公式ソースで鍵が見つからない場合、古い鍵リング、サポート対象外のリリース、誤ったソース、破損した環境などが考えられる。手動ダウンロードの前に OS のリリースと公式 URL を確認する。
第三者リポジトリでは、ベンダーの公式設定ページや鍵配布文書を使う。URL、公開者の身元、公開された完全なフィンガープリントを独立に結び付けられなければ、そのソースを無効にして止める。任意の鍵を取り込んでも、エラーが変わるだけで運営者の確認にはならない。
3. インストール前に完全な指紋を照合
確認済みの公開者経路から候補の公開鍵を一時ファイルへ取得する。`gpg --show-keys --with-fingerprint --with-subkey-fingerprint /path/to/candidate-key` で表示し、信頼済み鍵リングには追加しない。主鍵の完全なフィンガープリントを、所有者の別の公式ページに掲載された値と一文字ずつ比較する。
末尾の8文字や16文字が NO_PUBKEY と一致するだけで承認しない。鍵サーバーの結果、掲示板のコマンド、リダイレクト、見慣れたユーザー ID も身元確認の代わりにならない。公式文書に鍵の更新がある場合、旧鍵と新鍵の指紋、適用される手順を先に記録する。
4. 正しい形式の専用鍵リングを用意
必要なら /etc/apt/keyrings を作り、root 所有でディレクトリを通過できる権限にする。ASCII armor の公開鍵は .asc、エクスポートしたバイナリ OpenPGP 鍵リングは .gpg を使う。Debian は現代の GnuPG keybox と APT 鍵リングを区別している。個人の GnuPG ホームや keybox をコピーしない。
指紋確認後、公開鍵のデータだけを専用名のファイルへ配置し、root 所有・0644 にする。file、gpg --show-keys --with-fingerprint、stat と `sudo -u _apt test -r /etc/apt/keyrings/vendor-archive-keyring.asc` で確認する。最後の確認が失敗したら namei -l で親ディレクトリをすべて調べる。ファイルが読めても親を通過できなければ _apt はアクセスできない。
5. Signed-By でリポジトリの鍵を限定
deb822 の .sources では、確認済み URI と suite のスタンザに `Signed-By: /etc/apt/keyrings/vendor-archive-keyring.asc` を追加する。従来の .list では、deb の直後のオプション用角括弧に `signed-by=/etc/apt/keyrings/vendor-archive-keyring.asc` を入れる。実際に配置した .asc または .gpg を使い、拡張子と形式を一致させる。
Signed-By はそのリポジトリを認証できる鍵を限定する。第三者鍵をすべて全体の信頼設定に置くより範囲を絞れるが、配布パッケージの無害性を保証しない。一つずつ移行して元の設定を保存し、限定したソースの検証成功までは古い全体設定の鍵を削除しない。指定ファイルに複数の公開鍵があり指紋で絞らなければ、それらすべてが許可される。ファイル全体を確認し、由来不明の鍵束を信用せず、公開者が示す選択方法に従う。
6. 終了コードだけでなく検証結果を確認
不安全なオプションなしで `sudo apt-get update` を実行する。対象のリポジトリが取得・認証され、NO_PUBKEY、無効な署名、読み取り不能の鍵リングに関するメッセージがないことを確認する。成功したホスト名と suite が最初の対象と一致する必要がある。別のミラーの成功では、元の項目の修復を証明できない。
そのリポジトリから取得する予定のパッケージについて `apt-cache policy PACKAGE_NAME` を調べ、候補バージョンと取得元を確認する。ソースファイルの場所、URI と suite、確認済み指紋、鍵リングの場所と SHA-256、モード、更新結果、パッケージ取得元を記録する。後の鍵更新や調査で、記録のないインポートより役立つ。
7. 認証を弱めず、失敗の原因を調べる
指紋が違う、公式ページが利用できない、有効期限切れや失効に公式の後継案内がない、身元が突然変わった場合は、利用を止め公開者へ問い合わせる。指紋が一致しても NO_PUBKEY が続くなら、Signed-By のパス、形式、_apt の読み取り、重複項目、Release メタデータが本当にその鍵で署名されたかを再確認する。
trusted=yes、allow-insecure=yes、Acquire::AllowInsecureRepositories、認証なしのインストールは、問題を検知した制御を弱める。Debian はこれらを安全性を下げる例外として説明しており、鍵修復の手順ではない。公開者、鍵、署名済みメタデータのつながりを検証できるまで、リポジトリを無効にしておく。
