GitHub CLI Linux パッケージが新しい PGP 署名キーに切り替わる：影響範囲と更新手順

GitHub CLI Linux パッケージが新しい PGP 署名キーに切り替わります。結論だけ先に言うと、Linux で公式の apt / yum / dnf / zypper リポジトリから gh を導入していて、2026年4月8日より前の設定をそのまま使っている環境は、新しい keyring か repo 設定を取り込んでおくべきです。更新済みの keyring には旧キーと新キーの両方が含まれており、これを反映しておけば、旧キーが 2026年9月5日 に失効したあとも apt update や dnf update が失敗しにくくなります。Windows/macOS、Homebrew、Conda、プリコンパイル済みバイナリ、ソースビルドは今回の直接の対象外です。 (The GitHub Blog)

GitHub CLI Linux パッケージで何が変わったのか

GitHub は 2026年4月8日付の changelog で、GitHub CLI の Linux パッケージ向け PGP keyring を更新し、新しい置き換え用キーを追加したと案内しました。公式の Linux インストールガイドでも、GitHub CLI の Linux パッケージとリポジトリ metadata を検証するための fingerprint として、旧キーと新キーの両方が掲載されています。つまり今回の「信頼設定の更新」は、gh 本体の再設定というより、パッケージマネージャー側が参照する鍵情報を新しい状態にする作業です。 (The GitHub Blog)

確認しておきたい fingerprint は次の 2 つです。 (GitHub)

キー	フィンガープリント	状態
旧キー	2C6106201985B60E6C7AC87323F3D4EA75716059	2026年9月5日に失効予定
新キー	7F38BBB59D064DBCB3D84D725612B36462313325	今後の検証で使われる新キー

APT では この 2 本が local keyring に入っているか、RPM 系では repo を再追加したときに新キーを取り込めるか が実務上の見どころです。GitHub は、2024年9月の期限切れで Linux パッケージの導入・更新に支障が出た経験を踏まえ、今回は前倒しでローテーションしていると説明しています。 (GitHub)

自分の環境が対応対象かを先に判定する

GitHub の案内を整理すると、対応要否はほぼ次の表で判断できます。 (The GitHub Blog)

あなたの状況	対応要否	理由
2026年4月8日以降に公式手順で gh を初回導入した	原則不要	新しい keyring がすでに含まれている
2026年4月8日より前に apt で導入し、その後インストール手順をやり直していない	必要	local keyring が旧キーのみの可能性が高い
2026年4月8日より前に dnf / yum / zypper で導入し、その後 repo 設定を取り直していない	必要	RPM 側に新キーを取り込めていない可能性がある
Homebrew / Conda / コミュニティパッケージ / プリコンパイル済みバイナリ / ソースビルド	不要	GitHub CLI の公式 Linux パッケージ用 PGP キーを使わない
Windows / macOS	不要	今回の変更対象外

日付を思い出せないときは、インストール履歴を掘るより 鍵の状態を直接見る ほうが確実です。ここを先に確認すると、不要な再設定を避けられます。 (GitHub)

Debian/Ubuntu で新しい GitHub CLI Linux 署名キーの信頼設定を更新する

まず local keyring を確認する

Debian/Ubuntu では、APT が参照している keyring に 旧キーと新キーの 2 本が入っているか を見れば判断できます。gpg が無い場合は gnupg を入れてから確認します。 (GitHub)

# gpg が無い場合
sudo apt update
sudo apt install gnupg

# 推奨パス
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

# 古い環境で使われていることがあるパス
gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg

# どの keyring を参照しているか確認したいとき
cat /etc/apt/sources.list.d/github-cli.list

gpg --show-keys の結果に、上の 2 つの fingerprint が両方出ていれば更新済みです。旧キーしか出ない場合は、keyring を差し替えてください。APT ソース定義の signed-by= がどのファイルを見ているかも、あわせて確認しておくと安全です。 (GitHub)

keyring ファイルを差し替える

既存の APT 利用者向けに GitHub が案内している要点は、新しい keyring を再取得してから apt update をやり直す ことです。curl なら次の流れで更新できます。 (GitHub)

sudo mkdir -p -m 755 /etc/apt/keyrings
sudo curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
sudo apt update
sudo apt install gh

古い環境では keyring が /usr/share/keyrings/ に置かれていることがあります。その場合は、実際に signed-by= が指している場所 に対して更新するか、github-cli.list の参照先を /etc/apt/keyrings/githubcli-archive-keyring.gpg に合わせてください。keyring の保存先と signed-by= の参照先がズレていると、更新したのにエラーが残る、という失敗が起こりやすいです。 (GitHub)

更新後に確認しておきたいこと

更新後は、もう一度 gpg --show-keys で 2 本の fingerprint が見えるか確認しておくと安心です。apt update が通ることと、gh の導入・更新が通常どおり進むことを合わせて確認すれば、Debian/Ubuntu 側の対応はほぼ完了です。 (GitHub)

RPM 系ディストリビューションで新しい GitHub CLI Linux 署名キーを取り込む

RPM 系では、Debian/Ubuntu のように keyring ファイルを直接差し替えるというより、repo 設定を取り直して RPM keyring に新キーを取り込ませる のが基本です。まずは今の状態を確認します。 (GitHub)

rpm -qa gpg-pubkey | xargs -I{} sh -c 'rpm -qi {} | grep -q "[email protected]" && echo {}'

GitHub CLI のキーが 1 件しか出ないなら、旧キーしか入っていない可能性があります。2 件目が見えていれば、すでに新キーを取り込めている可能性が高いです。 (GitHub)

DNF5 の場合

dnf --version で DNF5 系だと分かったら、repo 定義を上書きで取り直します。GitHub の案内では Fedora 41 以降の例として DNF5 手順が示されています。 (GitHub)

sudo dnf install dnf5-plugins
sudo dnf config-manager addrepo --overwrite --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf update gh

DNF4 の場合

CentOS、RHEL、Fedora 40 以前などで DNF4 を使っているなら、config-manager プラグインを入れてから repo を追加し直します。 (GitHub)

sudo dnf install 'dnf-command(config-manager)'
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf update gh

Yum の場合

Amazon Linux 2 などで yum を使う環境では、repo を追加し直してから更新します。 (GitHub)

sudo yum install yum-utils
sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo yum update gh

Zypper の場合

openSUSE / SUSE では、既存 repo をいったん外してから追加し直す手順です。 (GitHub)

sudo zypper removerepo gh-cli
sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo
sudo zypper update gh

更新時にキー import の確認が出たら、旧キー 2C6106201985B60E6C7AC87323F3D4EA75716059 と 新キー 7F38BBB59D064DBCB3D84D725612B36462313325 に一致しているか見てから進めると安全です。ここを流してしまうと、「確かに import したのに違うキーだった」という事故を防げません。 (GitHub)

Docker build と CI で止まらないようにする

見落としやすいのが Docker です。前のレイヤーで GitHub CLI repo を追加し、後ろのレイヤーで apt update を実行する Dockerfile は、古い keyring を持ったままだと将来ビルドが止まる可能性があります。GitHub は、keyring を追加したレイヤーを再ビルドするか、apt update の前に新しい keyring を取得するレイヤーを差し込むよう案内しています。 (GitHub)

RUN curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \
    && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg

gh をまったく使っていないのにベースイメージ由来で repo だけ残っている場合は、repo 定義を削除して apt update の検証対象から外す、という整理も有効です。不要な repo は、使っていない限り残さないほうが運用が軽くなります。 (GitHub)

よくあるエラーと失敗しやすいポイント

GitHub が例示している典型エラーを、実務向けに整理すると次のようになります。 (GitHub)

症状・エラー例	起きやすい原因	まずやること
EXPKEYSIG 23F3D4EA75716059	旧キーのまま検証している	APT keyring を再取得する
NO_PUBKEY 5612B36462313325	新キーが local keyring に無い	新しい keyring を取り込む
unknown key '5612B36462313325' / GPG check FAILED	RPM 側が新キーを読めていない	repo を再追加して更新をやり直す
keyring を更新したのに改善しない	signed-by= が別パスを見ている	github-cli.list の参照先を確認する
repo 再追加後も RPM が失敗する	旧キーが RPM keyring に残って競合している	古いキーを削除して gh を入れ直す

特に APT でハマりやすいのは、keyring を更新したつもりでも、APT が別の場所の keyring を参照している ケースです。RPM でハマりやすいのは、repo を追加し直しただけでは古いキーの残骸が悪さをする ケースです。どちらも「ファイルの場所」と「実際に使われる鍵」を分けて確認すると切り分けが早くなります。 (GitHub)

RPM でまだ失敗する場合の最終手順

GitHub の案内では、repo を再追加してもダメなら、古い PGP キーを RPM keyring から外して gh を入れ直す手順が示されています。古いキー名は gpg-pubkey-75716059-63172e8a か、fingerprint 全体を含む長い名前で出ることがあります。まず Packager が GitHub CLI <[email protected]> か確認してから削除してください。 (GitHub)

sudo rpm -qa gpg-pubkey
sudo rpm -qi gpg-pubkey-75716059-63172e8a
sudo rpm -e gpg-pubkey-75716059-63172e8a
sudo dnf remove gh
sudo dnf install gh

yum や zypper 環境なら、最後の再導入部分だけ自分のパッケージマネージャーに読み替えます。ここまで必要になるケースは多くありませんが、再追加したのに署名検証だけ直らない ときには有効です。 (GitHub)

迷ったら、この順で対応すれば十分

GitHub CLI Linux パッケージの新しい PGP 署名キー対応で、実際にやることは多くありません。迷ったら次の順で進めれば十分です。 (The GitHub Blog)

• gh を 公式 Linux リポジトリ から入れたか確認する
• APT なら local keyring に 2 本の fingerprint があるか確認する
• RPM 系なら repo を再追加し、新キーの import が出るか確認する
• Docker/CI では apt update や dnf update の前に keyring/repo 更新を入れる
• 更新後に apt update または dnf update gh を 1 回通しておく

最優先は「いつ入れたか」を思い出すことではなく、今の鍵状態を確認することです。2026年4月8日以前の設定を引きずっている Linux 環境だけを確実に直せば、不要な作業を増やさずに、期限切れ後の更新停止もかなり防げます。 (GitHub)