VPN リポジトリを追加した後、NO_PUBKEY で apt の更新が失敗する

NO_PUBKEY と Release ファイルの欠落はネットワーク障害ではなく信頼の失敗だ。ベンダーの鍵を signed-by で固定するか、ソースを削除するかを決める。

VPN ベンダーの apt ソースがパッケージマネージャーを壊してしまった。その修正はコマンドではなく判断だ。 NO_PUBKEY、あるいはリポジトリに Release ファイルがないという警告は、apt がそのソースを信頼しないと判断したという意味であり、以後のパッケージ操作は同じ警告を出し続ける。トンネル自体はおそらく無関係だ。そのソースを今後も必要とするかどうか、三つの問いに答えれば正しい修理はほぼ機械的に決まる。

まず、失敗を正しい分類に置く

信頼の失敗は、ソースファイル名と、欠けている鍵または存在しない Release ファイルを示す。転送の失敗は見た目が違う。TLS 証明書のエラー、接続の拒否、タイムアウト、あるいは CONNECT を拒否するプロキシだ。この区別が、どの記事を読むべきかを決める。TLS を傍受したりベンダーのホストを遮断したりする VPN は、署名のエラーではなく転送のエラーを生む。

sudo apt updateだけを実行し、その上に並ぶキャッシュ済みの行は無視して末尾を読む。重要な行には /etc/apt/sources.list.d/ が示され、開くべきファイルが分かる。

トンネルが上がった直後に失敗する場合 は、トンネルを落とした状態と、DNS をシステムのリゾルバーで解決した状態で試す。VPN なしで機能するソースなら、それは経路や傍受の問題であり、鍵の管理では解決しない。

進む道を選ぶ三つの問い

このソースから今もパッケージを導入・更新しているか。クライアントを現役で使っているなら信頼を修理する。一度だけ導入し、今は NetworkManager に普通のプロファイルを取り込んでいるだけなら、そのソースは無用の重りであり、削除が誠実な修正だ。

次に、ベンダーは帯域外で検証できる鍵とフィンガープリントを公開しているか。最後に、このホストの鍵を管理するのはディストリビューションか、それとも自分か。検証できない鍵で署名されたソースは、与えるべきでない更新の権限だ。

最初の問いに否と答えた時点で分析は終わる。三つすべてに是なら signed-by による修理に進む。それが機能し、なおかつ監査可能であり続ける唯一の構成だ。二つの道を混ぜ、ソースを残したまま無理に通すことだけは、明示的に排除する価値がある。

trusted=yes が修正に見えてそうでない理由

sources.list のマニュアルページ はこの点を明言している。Trusted オプションを yes にすると、認証に失敗してもソースを受け入れるよう apt に指示することになり、そのリポジトリの apt-secure が無効になる。ページはこれを、使うとしてもローカルな文脈に限っている。

これはベンダーを信頼する狭い版ではない。索引に誰が署名したかという問いを消してしまうので、そのホスト名に答えられる者なら誰でも、root として導入されるパッケージをあなたの機械に渡せる。

修理の道：鍵を取得し、それから固定する

鍵はベンダーが文書化している場所から取得し、管理者が管理するキーリングに展開する。そのうえでリポジトリの行をそのファイルに向け、信頼がずれないようにする。

  1. 失敗している行を読み、鍵の ID とソースのファイル名を取る。
  2. ベンダーの ASCII 装甲鍵をダウンロードし、gpg --dearmor を /etc/apt/keyrings/vendor-name.gpg に対して実行する。
  3. [signed-by=/etc/apt/keyrings/vendor-name.gpg] を、そのベンダーの .list ファイルの項目に追加する。
  4. sudo apt update を実行し、署名警告を繰り返す代わりに索引を取得することを確認する。

パッケージと一緒に届く鍵には /usr/share/keyrings を、手で置く鍵には /etc/apt/keyrings を優先する。この分け方は見た目の話ではない。次の管理者に、どの鍵がパッケージ更新を生き延び、どれが人の手を要するかを伝える。

信頼する前に、フィンガープリントをベンダーの公開値と照合する。フォーラムの投稿から貼り付けた鍵 ID は、誰も名指しできない更新の権限を機械が信じ始める入り口だ。

削除の道、そしてエラーが戻りうる理由

インストーラーが実際に何を書いたかを見る。同じベンダーを指すファイルが複数あることが多く、その一つはたいてい取り残された複製だ。

grep -r . /etc/apt/sources.list.d/
sudo rm /etc/apt/sources.list.d/vendor.list

apt はそのディレクトリから .list と .sources だけを読むので、.save や .distUpgrade の複製はすでに無視される。それでも消しておけば、後から読む者が誤って復元することはない。ソースを消しても何かがアンインストールされるわけではなく、apt は導入済みの VPN パッケージをローカル導入または入手不可として示すことがあるが、それはパッケージ状態のメッセージであって、信頼エラーの再来ではない。

繰り返されるのは、鍵を apt-key で大域の信頼リングに入れていた古い手順だ。その道は非推奨であり、リリース更新で鍵が落ちたり単に参照されなくなったりする。一年間静かだったエラーが更新した週に現れるのは、まさにそのためだ。/etc/apt/trusted.gpg.d/ を確認し、信頼の判断をそれが属するリポジトリの行へ移す。ベンダーが今も apt-key の手順を載せているなら、それでも signed-by を使う。マニュアルが記述している構成であり、更新を生き延びるのはこちらだ。

関連記事