GitHub CLIの旧PGP鍵が失効、Linux更新停止を新鍵で直す

GitHubが2026年9月3日に予告したGitHub CLI公式Linuxリポジトリの旧PGP鍵は、9月5日に失効した。GitHubの告知 によると、失効後の最初のリリースから、APT・RPMのリポジトリメタデータと新しいRPMパッケージは交換鍵だけで署名される。

旧鍵しか信頼していない対象環境では、署名を検証できず、パッケージ一覧の取得やghの更新が止まる。9月7日更新の 独立した技術解説 も、影響が公式APT・RPMリポジトリの古い設定に限られ、インストール済みのghバイナリ自体が失効と同時に動かなくなるわけではないと整理している。

公式リポジトリを使う環境か判定する

対象になるのは、主に2026年4月8日より前にGitHub公式のAPTまたはRPMリポジトリからghを導入し、その後リポジトリ設定を更新していないLinux環境だ。Windows、macOS、ソースビルド、Homebrew、Conda、コミュニティーパッケージ、GitHub Releasesの単体バイナリや直接取得したDEBファイルには、今回のリポジトリ鍵は使われない。

DebianやUbuntuでは「cat /etc/apt/sources.list.d/github-cli.list」を実行し、GitHub CLIのリポジトリ定義と「signed-by=」が指すkeyringを確認する。現在の標準的な場所は「/etc/apt/keyrings/githubcli-archive-keyring.gpg」だが、古い設定では「/usr/share/keyrings/githubcli-archive-keyring.gpg」が指定されていることもある。

Fedora、RHEL、CentOS、Amazon Linux 2、openSUSE、SUSEでは、「rpm -qa gpg-pubkey | xargs -I{} sh -c 'rpm -qi {} | grep -q "[email protected]" && echo {}'」でGitHub CLI用の登録鍵を探せる。「EXPKEYSIG」「NO_PUBKEY」「GPG check FAILED」、または新鍵の短いID「5612B36462313325」が表示され、エラーの対象が「cli.github.com/packages」なら、この鍵交換に該当する可能性が高い。

新鍵は40桁の完全な指紋で照合する

新鍵の完全な指紋は7F38BBB59D064DBCB3D84D725612B36462313325、失効した旧鍵は「2C6106201985B60E6C7AC87323F3D4EA75716059」だ。2026年4月8日に公開された GitHub CLIチームの公式手順 には、両方の指紋とエラー例、APT、DNF、YUM、Zypper、Docker別の移行方法がまとめられている。

APTでは、リポジトリ定義が参照するファイルに対して「gpg --show-keys keyringのパス」を実行する。新旧2個の公開鍵と両方の完全な指紋が表示されれば更新済みで、今回の失効を理由にkeyringを再交換する必要はない。旧鍵だけの場合、またはファイルが見つからない場合は更新が必要だ。

鍵を取得できたことと、正しい鍵を信頼できることは別である。登録前に「gpg --show-keys --with-fingerprint ダウンロードしたファイル」を実行し、空白を除いた40桁すべてが公式値と一致するか確認する。末尾16桁や所有者名だけの一致を根拠に信頼してはいけない。

APTは参照中のkeyringを更新する

既存のAPT利用者は、GitHubが配布する更新済みkeyringで、実際に「signed-by=」から参照されているファイルを置き換える。標準パスを使う場合は次の順序になる。

1. 「sudo mkdir -p -m 755 /etc/apt/keyrings」で保存先を作る。
2. 「sudo curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg」でkeyringを取得する。
3. 「sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg」でAPTから読み取れる権限にする。
4. 「gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg」で新旧2鍵を表示し、新鍵の完全な指紋を照合する。
5. 「sudo apt update」を実行し、続けて「sudo apt install gh」で更新する。

リポジトリ定義が「/usr/share/keyrings」など別の場所を参照しているなら、取得先もそのパスに合わせるか、「signed-by=」を正しい保存先へ変更する。「/etc/apt/keyrings」に新しいファイルを置いただけでは、APTが古いファイルを参照し続ける場合がある。

更新済みkeyringに失効した旧鍵が残っていても、それだけで異常ではない。交換鍵の完全な指紋も同じkeyringにあり、APTの設定がそのファイルを参照していることが判断基準になる。

DNF・YUM・Zypperはリポジトリ定義を再取得する

RPM系では、新しい鍵を任意の取得元から追加するのではなく、交換鍵を参照する公式リポジトリ定義を再取得する。ghの更新時に鍵のインポート確認が出たら、新鍵の完全な指紋と一致することを確かめてから承認する。

• DNF5を使うFedora 41以降は「sudo dnf config-manager addrepo --overwrite --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo」を実行し、続いて「sudo dnf update gh」を実行する。
• DNF4を使うRHEL、CentOS、Fedora 40以前は「sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo」の後に「sudo dnf update gh」を実行する。
• Amazon Linux 2のYUMは「sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo」と「sudo yum update gh」を使う。
• Zypperは「sudo zypper removerepo gh-cli」で旧定義を外し、「sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo」で再登録してから「sudo zypper update gh」を実行する。

再登録後も署名検証に失敗するときは、RPM keyringに残った旧鍵の削除が必要な場合がある。旧鍵名は通常「gpg-pubkey-75716059-63172e8a」などだが、削除前に「sudo rpm -qi 鍵名」でPackagerが「GitHub CLI <[email protected]>」か確認する。名前だけを推測して鍵を削除すると、別の配布元まで壊しかねない。

Dockerはapt updateより前に鍵を置き換える

古いDockerレイヤーがGitHub CLIリポジトリを追加し、後続レイヤーで「apt update」または「apt-get update」を実行する構成も対象になる。更新済みkeyringの取得と読み取り権限の設定を、最初のパッケージ一覧更新より前に置く。

鍵を追加するレイヤーを管理できるなら、常に最新のkeyringを取得するようDockerfileを修正して再構築する。ベースイメージ側を変更できない場合は、aptによる更新より前に、同じ参照先へ更新済みkeyringを書き込むレイヤーを加える。確認時に古いレイヤーが再利用されるなら、キャッシュを使わないビルドで設定を検証する。

ベースイメージにGitHub CLIリポジトリが残っているだけで、コンテナ内や派生イメージでghを使わないなら、「/etc/apt/sources.list.d/github-cli.list」を削除して更新対象から外せる。ghをAPTで継続更新する環境には使えないため、削除前にDockerfileと派生イメージの依存関係を確認する。

署名検証を保った更新完了が復旧条件

復旧したと判断できるのは、署名検証を無効にせず、対象リポジトリのメタデータ取得とghのインストールまたは更新が完了したときだ。「--allow-unauthenticated」や「--nogpgcheck」で迂回すると、交換鍵による配布元確認が働かず、鍵失効の問題を解決したことにはならない。

新鍵を登録しても失敗する場合は、GitHub CLIリポジトリの重複登録、古い「signed-by=」や「gpgkey=」の参照先、社内ミラー、プロキシキャッシュを確認する。通信や名前解決の障害、ディストリビューション側の問題など、署名鍵以外の原因はkeyringの交換では直らない。

旧鍵の失効はすでに完了し、交換鍵だけで署名された新しい配布物を受け取る対象環境では対応が必要になった。ただし、すべてのLinux利用者が対象ではない。導入経路を絞り込み、交換鍵の40桁の指紋を照合し、利用中のパッケージ管理ツールに対応する公式手順を適用することが、安全な復旧条件となる。