apt-keyの仕組みと問題点

apt-keyはシステム上のリポジトリ鍵を管理するコマンドです。

apt-keyコマンドはAPTキーリング（/etc/apt/trusted.gpg）に，リポジトリ鍵としてGPG公開鍵を登録・削除します。つまり実態はGPGのキーリングそのものであり，GPGの鍵管理を行っているだけです。Ubuntuのインストール直後はUbuntuの公式リポジトリとインストーラーイメージの鍵しか登録されていませんが，PPA等のサードパーティのリポジトリを追加するごとに，ここに新しい鍵が追加されることになります。これにより，正しく運用されているリポジトリであれば，公式リポジトリと同じように安全にパッケージをダウンロードできるのです。

よく紹介される例は第458回の「UbuntuでDocker再入門」のようにサードパーティのリポジトリを追加する例ですね。最近はZoomやSlackのように，独自に「Linux向けバイナリパッケージ」を配る際も，パッケージリポジトリを作りアップデートの仕組みを提供することが増えてきました（※5⁠）⁠。このため各ベンダーは「まずはリポジトリの鍵をダウンロード・インストールする」ために，apt-keyを使う方法を提案しています。

※5

独自パッケージリポジトリを作成・公開したい場合は第485回の「aptlyで本格的なパッケージリポジトリを作る」も参考になるでしょう。

そんな「apt-key」コマンドですが，2020年8月の2.1.8から「廃止予定（deprecated⁠）⁠」となり，2022年の半ばには削除されることになりました（※6⁠）⁠。たとえばUbuntu 20.04 LTSのmanページだとタイトルが「apt-key - APT key management utility」だったのが20.10のmanページでは「apt-key - Deprecated APT key management utility」となっています。

※6

まもなくリリース予定のDebian 11ではapt-keyは残される予定です。来年リリース予定であるUbuntu 22.04 LTSでも残っている可能性はあります。それ以降のリリースは特別な理由がない限り削除される見込みです。

また，実際にUbuntu 21.04などでapt-keyコマンドを使うと，次のような警告が表示されます。

Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).

これはセキュリティ上の懸念点からくるもので，簡単にまとめると次の2点が理由です。

1. apt-key addは単一ファイル（/etc/apt/trusted.gpg）に鍵を追加していくため，複数のリスクの異なるリポジトリの鍵を同じ権限で管理しなくてはならない。
2. リポジトリ鍵として追加した鍵は，すべてのリポジトリに対して適用される。

実はどちらも昔から言われていたことで，「⁠apt-keyはもう使うべきではない」というのは，遅くともDebian 9がリリースされた2017年頃には開発者側の共通見解だったようです。

1についてはapt-key addを使わずに，/etc/apt/trusted.gpg.d/以下に個別のリポジトリ鍵を置くという回避策があります。実際，Ubuntuの公式リポジトリの鍵は，上記のようにこの手法をとっています。しかしながらたとえファイルを分割したところで2については回避できません。

APTのリポジトリ鍵は「リポジトリの管理者を信頼する」つまり「そのリポジトリサーバーが正しく運用されていることを期待する」前提に立っています。しかしながらリポジトリ鍵を「/etc/apt/trusted.gpg{,.d/}」に取り込んでしまうと，あるサードパーティのリポジトリに問題が発生したとき，その影響範囲がシステムにインストールされているすべてのパッケージに波及することにほかなりません（※7⁠）⁠。

※7

apt-pinningでリポジトリの優先度を設定していればある程度は緩和可能です。

結局のところ「/etc/apt/trusted.gpg.d」は，「⁠システムで利用するすべてのリポジトリ」に対するチェックを行うための鍵を置く場所なので，リスクの異なるサードパーティのリポジトリの鍵も同じように扱うのはおかしいという，ただそれだけの話です。

現時点ではapt-keyの代替となるCLIは用意されていないようです。

今後リポジトリ鍵はどう運用すべきか

すべての利用者がサードパーティのリポジトリの利用をまったくやめることは難しいため，引き続き何らかの形でリポジトリ鍵を取り込む必要があります。では，apt-keyがなくなったあとの「ベストプラクティス」はどうなるのでしょうか。

まもなくリリース予定のDebian 11の2021年7月17日時点でのリリースノートでは，/etc/apt/trusted.gpg.d/に個別にリポジトリ鍵を保存する方法を提案しています。apt-keyコマンドを実行したときの警告も同様です。

これはこれまでapt-key addに渡していたリポジトリ鍵を，単に/etc/apt/trusted.gpg.d/に保存するだけというシンプルなものです。このときバイナリ形式なら拡張子「gpg」を，ASCII形式なら「asc」を利用します。ただし一般的に配布されているリポジトリ鍵はASCII形式であることが大半で，さらにAPTでサポートしているフォーマットでない可能性があります。

よって次のような手順で，一旦適当な鍵束に取り込んでから，バイナリ形式でエクスポートするのが安全なようです。

$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
    --import "ダウンロードしたリポジトリ鍵ファイル名"
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
    --export --output "リポジトリ名".gpg
$ rm /tmp/temp-keyring.gpg
$ sudo cp "リポジトリ名".gpg /etc/apt/trusted.gpg.d/

しかしながら，この方法ではサードパーティのリポジトリに対するリスク管理という観点からは，完全な対応とは言えません。実際，Debian Wikiにある情報ではあるもののサードパーティのリポジトリの利用のページにおいて，apt-keyコマンドだけでなく/etc/apt/trusted.gpg.d/の利用も「MUST NOT（してはならない⁠）⁠」と記述しています。

より良い手順は，/usr/local/share/keyrings/に鍵を保存しておき，sources.listからリポジトリごとに参照する鍵を指定する方法です。

$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
    --import "ダウンロードしたリポジトリ鍵ファイル名"
$ gpg --no-default-keyring --keyring /tmp/temp-keyring.gpg \
    --export --output "リポジトリ名".gpg
$ rm /tmp/temp-keyring.gpg
$ sudo mkdir -p /usr/local/share/keyrings/
$ sudo cp "リポジトリ名".gpg /usr/local/share/keyrings/

ただしこれだけだとAPTからダウンロードしたリポジトリ鍵を参照できません。次にsources.listに鍵を指定するオプションを付けます。おそらくサードパーティのリポジトリを導入する際には，リポジトリの場所を「/etc/apt/sources.list.d/リポジトリ名.list」みたいなファイルを作ってそこに記述するでしょう。そこでその内容を次のように書き換えます。

変更前：
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main

変更後：
deb [arch=amd64 signed-by=/usr/local/share/keyrings/"リポジトリ名".gpg] http://dl.google.com/linux/chrome/deb/ stable main

つまりdebの後ろに「[signed-by=/usr/local/share/keyrings/"リポジトリ名".gpg]」を追加するわけです。上記はすでに「[arch=amd64]」がある例ですが，ない場合は「[]」から追加してください。「⁠[]」の中のオプションは空白で連結可能です。

これによりダウンロードしたリポジトリ鍵は，特定のリポジトリの検証にのみ利用できるようになりました。

おそらく当分の間，サードパーティのリポジトリの導入手順は「apt-keyコマンドを使う方法」が紹介されるでしょう。しかしながら今後は将来apt-keyが廃止されることを考慮して，上記のような手順に変更することも検討してもらえればと思います（※8⁠）⁠。

※8

PPAの追加でよく使われる「add-apt-repository」はまだapt-keyコマンドを内部で利用しています。こちらも将来的には何らかの対応が行われると思われます。

ちなみに前述のサードパーティのリポジトリを利用することについて解説したDebian Wikiのページでは，リポジトリを運用する側がどのような名前の鍵ファイルをどのように配布すべきかについても解説されています。apt-keyの完全な廃止に向けて，リポジトリの運用を見直す際には参考になるでしょう。