APTリポジトリ署名鍵のsigned-by移行｜旧形式混在環境での段階切り替えと整合性確認

APTリポジトリの署名検証は、パッケージの改ざん防止において重要な役割を担います。しかし従来の apt-key コマンドを使った鍵管理方式は、Debian系ディストリビューションにおいて長らく非推奨とされており、現行の環境では signed-by オプションを用いた方式への移行が標準となっています。旧形式のままにしておくと、apt update 時に警告が表示されるだけでなく、将来的にパッケージ更新が止まるリスクもあります。

本記事では、旧形式（apt-key 登録・trusted.gpg.d）と新形式（signed-by）が混在する実環境で、安全に段階的な切り替えを行う手順を解説します。

APT署名鍵の旧形式と signed-by 形式の違い

旧来のAPT鍵管理では、apt-key add コマンドを使って公開鍵を /etc/apt/trusted.gpg や /etc/apt/trusted.gpg.d/ に追加するのが一般的でした。この方式の問題点は、追加した鍵がシステム上のすべてのリポジトリに対して暗黙的に信頼されてしまうことです。悪意のあるリポジトリの鍵を誤って追加した場合、他のリポジトリのパッケージも偽装されるリスクが生じます。

signed-by 形式では、.list または .sources 形式のリポジトリ定義ファイルに signed-by= オプションを記述し、鍵ファイルのパスを明示的に指定します。これにより、特定のリポジトリに対してのみ鍵を紐付けることができ、鍵の影響範囲が限定されます。

鍵ファイルの推奨保存場所は /usr/share/keyrings/（システム全体向け）または /etc/apt/keyrings/（管理者が追加したもの）です。Ubuntu 22.04以降・Debian 11以降の公式ドキュメントでは、後者の /etc/apt/keyrings/ が推奨されています。

旧形式が混在する環境で起きる問題

apt update 実行時に以下のような警告が表示されるケースは、旧形式の鍵が残っている典型的なサインです。

W: http://packages.example.com/debian: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.

この状態は即座にアップデートが失敗するわけではありませんが、将来のディストリビューションバージョンアップやAPTのメジャーアップデート後に問題が表面化することがあります。また、監査要件が厳しい環境では「鍵管理が旧来のまま」という指摘につながる可能性もあります。

一般的には、サードパーティ製ソフトウェアのインストールスクリプトが旧来の方式で鍵を追加したまま放置されているケース、あるいは古い手順書をそのまま踏襲した結果として旧形式が混入するケースがよくあるつまずきとして挙げられます。

signed-by 移行の手順（段階切り替え）

旧形式と新形式が混在する環境では、一括変換よりもリポジトリごとの段階移行が安全です。以下の手順をリポジトリ単位で繰り返す形で進めます。

1. 現状の旧形式鍵を確認する

apt-key list

出力から、移行対象の鍵のfingerprint（40桁の16進数）を控えます。次に、どのリポジトリ定義ファイルがその鍵に対応しているかを確認します。

grep -r 'signed-by\|deb ' /etc/apt/sources.list /etc/apt/sources.list.d/

signed-by= が記述されていないリポジトリが移行対象です。

2. 鍵を新形式のファイルとしてエクスポートする

対象鍵のfingerprint（想定例: ABCD1234...）を使って、/etc/apt/keyrings/ にバイナリ形式の鍵ファイル（.gpg）としてエクスポートします。

sudo mkdir -p /etc/apt/keyrings
sudo apt-key export ABCD1234 | sudo gpg --dearmor -o /etc/apt/keyrings/example-archive-keyring.gpg

エクスポート後、鍵の内容を確認します。

gpg --no-default-keyring --keyring /etc/apt/keyrings/example-archive-keyring.gpg --list-keys

正しい鍵情報が表示されれば、エクスポートは成功です。

3. リポジトリ定義ファイルに signed-by を追加する

/etc/apt/sources.list.d/example.list を編集し、signed-by= を追加します。

変更前（想定例）：

deb [arch=amd64] https://packages.example.com/debian bullseye main

変更後（想定例）：

deb [arch=amd64 signed-by=/etc/apt/keyrings/example-archive-keyring.gpg] https://packages.example.com/debian bullseye main

4. 旧形式の鍵を trusted.gpg から削除する

必ず apt update が正常に通ることを確認してから、旧形式の鍵を削除します。

sudo apt update
# エラーがなければ削除へ
sudo apt-key del ABCD1234

削除後、再度 apt update を実行し、警告が消えたことを確認します。

移行後の整合性確認

移行完了後は以下の3点を確認します。

apt-key list の出力を確認する

apt-key list

Warning: apt-key is deprecated のメッセージの後に鍵情報が残っていないかを確認します。残っている場合は、対応するリポジトリ定義に signed-by= が設定されていない可能性があります。

apt update が警告なく完了するか確認する

sudo apt update 2>&1 | grep -E 'W:|E:'

W: や E: が表示されなければ、移行は正常に完了しています。

鍵ファイルのパーミッションを確認する

/etc/apt/keyrings/ 配下のファイルは root:root 644 が推奨です。APTはこのパスを読み取り専用で参照するため、一般ユーザーへの書き込み権限は不要です。

ls -la /etc/apt/keyrings/

切り戻し手順と作業上の注意点

移行作業は、旧形式の鍵を削除する前に必ず apt update の成功を確認する「二段階」で進めます。削除後に問題が発覚した場合は、以下の手順で一時的に旧形式へ戻せます。

# ASCII armor の鍵ファイルが手元にある場合
sudo gpg --dearmor < /path/to/key.asc | sudo apt-key add -

ただし apt-key add 自体が非推奨であるため、切り戻しは一時的な措置として扱い、速やかに原因を究明して移行を再試行することが望ましい対応です。

よくあるつまずきとして、signed-by= に指定したパスのファイルが存在しない・パーミッションが不正・鍵の内容がASCII armorのまま（.gpg と命名しているが実はarmor形式）というケースが挙げられます。gpg --dearmor を通したバイナリ形式かどうかは file コマンドで確認できます。

file /etc/apt/keyrings/example-archive-keyring.gpg
# → "PGP/GPG key public ring (v4)" と表示されれば正しいバイナリ形式

また、.sources 形式（DEB822形式）のリポジトリ定義を使用している場合は、Signed-By: フィールドに鍵ファイルのパスを記述する点に注意が必要です。.list 形式とは記法が異なります。

2026年現行環境での差分と注意点

Ubuntu では、24.04 LTS（Noble Numbat）以降、公式リポジトリの設定ファイルはすべて signed-by= 形式に統一されています。apt-key コマンドはパッケージとして引き続き存在しますが、将来のリリースでの完全削除を視野に入れた位置づけです。サードパーティのインストールスクリプトが旧来の apt-key add を使用している場合、スクリプト側の対応が遅れているケースがあります。

Debian では、Debian 12（Bookworm）以降が同様の方針を採っています。/etc/apt/keyrings/ ディレクトリはBookworm以降では初期状態で作成済みですが、Bullseye からのインプレースアップグレード環境では手動作成が必要な場合があります。

注意が必要な環境差分として、一部のコンテナイメージや LTS からのインプレースアップグレード環境では、旧形式の鍵が残ったまま新バージョンに移行しているケースがあります。apt update 時の警告有無を定期的に確認する運用フローを取り入れることで、問題の早期発見につながります。また、Ansible や Chef といった構成管理ツールを使っている環境では、鍵管理タスク自体を signed-by 対応のモジュールや手順に更新することが、継続的な整合性維持に効果的です。