HTTPS と VPN はインストールするパッケージを認証しない

更新が失敗し、スレッドの助言はお決まりの線をたどる：通信が VPN を通っているのだからダウンロードは信頼できるはずだ、という理由で、エラーを抜けるために署名検証が緩められる。別々の二つの考えが一つの文に融けている。暗号化が守るのは端点の間の経路であり、認証が決めるのはそのバイトが意図した発行者から来たかどうかである。トンネルは前者を与えるが、後者については何も語らない。

症状はたいてい、一つのホスト、一つのリポジトリだけで検証エラーが出て、ほかは正常に更新されるという形になる。この形はすでに、ネットワーク経路は機能しており、争点は信頼にあると告げている。

異なる問いに答える二つの制御

トランスポートの安全性が答えるのは、この接続の相手が誰か、経路上の誰かが読んだり改変したりできるかである。パッケージの認証が答えるのは、この成果物が設定した権威によって公開されたかであり、管理下にないミラー経由のダウンロードにも耐えなければならない。

両者が重なるのは端だけだ。ミラー上の正しい証明書は、ミラーがミラーであることを証明するが、ミラーが改変されていない発行者の内容を保持していることは証明しない。署名されたパッケージは、発行者が署名したことを証明するが、ネットワークが最新版を届けたことや、指定したリポジトリが組織の承認したものだということは教えてくれない。

検査を切ることで人が作り出す故障の形は、一度のダウンロード成功と引き換えに、第二の保証を恒久的に失うことだ。その取引は、それが問題になる日まで見えない。

apt が実際に認証するもの

APT のモデルは認証されたアーカイブの連鎖である。署名されたリリースメタデータがチェックサムでパッケージ索引へ導き、その索引がチェックサムで個々のパッケージファイルへ導く。この連鎖を検証することが、ミラーを信頼できないまま使えるものにする：ミラーは好きなものを配信でき、メタデータの署名が APT に受け入れさせるかを決める。

これは、インストール済みの各パッケージで保守者の署名を確認することとは意図的に異なり、その区別が、バグ報告で「パッケージは署名済み」と「アーカイブは認証済み」が別の意味なのに同じように使われる理由を説明する。

apt-get update
apt-cache policy
apt-config dump | grep -iE 'AllowInsecure|AllowDowngrade'

終了コードだけでなく更新の出力を読むこと。APT はメタデータが失敗したリポジトリを名指しし、その名前が調査すべき境界である。署名検証なしで信頼済みとされたリポジトリや、安全でないリポジトリの上書きは、誰かが下した設定上の判断であり、説明できるべきものだ。

鮮度もまた別の性質である。有効に署名されたメタデータファイルは、先週見たものより古いことがあり、だからこそリリースメタデータは有効期限を持ち、クライアントの時計の問題が鍵の問題に見える検証エラーを生むことがある。

dnf5 が別々に確認するもの

RPM 側は二つの異なるスイッチを公開しており、それらを混同すると逆方向に同じ種類の誤りを生む。一方はパッケージファイルが有効な署名を持つ必要があるかを制御し、他方はリポジトリのメタデータが署名されている必要があるかを制御する。独立に設定でき、片方に厳しく他方に甘いシステムもあり得る。

dnf5 config-manager --dump 2>/dev/null | grep -iE 'gpgcheck|repo_gpgcheck'
rpm -q --qf '%{NAME} %{SIGPGP:pgpsig}\n' bash

パッケージの問い合わせは、インストール済みの複製の署名メタデータがどうなっているかを示し、厳格さを主張する設定ファイルに対する有用な現実確認になる。それが教えないのはディストリビューションのサポートする方針であり、フォーラムの一般的な「GPG を有効にせよ」という指示ではなく、そちらに従うべきである。

二つの管理手段が異なるのは、どちらかが弱いという印ではなくアーキテクチャの違いである。どちらも発行者の内容を認証し、署名を連鎖の異なる位置に置く。

トンネルが加えるもの、加えないもの

VPN は必要な経路を提供し、更新の通信を信頼できない接続網の外に保ち、近くの観察者が見るものを減らせる。それらは現実の運用上の利点であり、いずれも発行者の認証ではない。

HTTPS は独自の保証を加えるが、感じられるより狭い。接続した TLS 端点を認証する。その端点がミラーであれば、認証したのはミラーであり、それが配信するアーカイブの内容ではない。まさにこれが、署名済みメタデータの連鎖が存在する理由の場面である。

どちらの制御も可用性を約束しない。ネットワークは配信を拒みうるし、認証された対象が自動的に最新とは限らない。鍵アイコンの有無から推測するのではなく、パッケージ管理機構自身の鮮度方針を使うこと。

失敗した境界を診断する

何かを変える前に段階を名指しする：DNS 解決、プロキシや経路、TLS 端点の同一性、アーカイブの認証、パッケージ署名の検査、あるいはインストールである。それぞれに固有の誤りの形と持ち主がある。

ネットワーク経路の修復に、未知の署名鍵を信頼済みと宣言すること、証明書を無視すること、頼んでいないリポジトリ設定を受け入れることが含まれてはならない。鍵が本当に更新されたなら、ディストリビューションやリポジトリの所有者が検証できる経路で新しい鍵を公開しており、それが適用すべき修正である。

どの境界が失敗し、誰がそれを持つのかを書き留める。次の更新の失敗は別の境界で起き、一覧があれば、トンネルが更新を安全にするかどうかをめぐる次の議論ではなく、五分の診断になる。