Quick answer: If you installed GitHub CLI (gh) from GitHub’s official APT or RPM repository before April 8, 2026, refresh the repository keyring now. GitHub’s old signing key expires on September 5, 2026, and systems that trust only that key may fail to install or update gh.[1][2]
30-second check for Ubuntu and Debian
Run:
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg
If that file does not exist, try GitHub’s documented older keyring location:[2]
gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg
You are ready for the rotation if the output contains GitHub’s new fingerprint:[2][3]
7F38BBB59D064DBCB3D84D725612B36462313325
If you see only the old fingerprint ending in 75716059, update the keyring using the steps below. GitHub’s official rotation notice says a keyring with both the old and new fingerprints is already updated.[2]
Ubuntu and Debian fix: copy and paste
First, check which keyring path your GitHub CLI repository actually uses:[2]
grep -o 'signed-by=[^] ]*' /etc/apt/sources.list.d/github-cli.list
The current recommended path is /etc/apt/keyrings/githubcli-archive-keyring.gpg. If your signed-by value points to /usr/share/keyrings/ instead, use that exact path in the download command so APT reads the file you replace.[2]
Update with curl
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
Or update with wget
sudo mkdir -p -m 755 /etc/apt/keyrings
sudo wget -qO /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
These commands follow GitHub’s official rotation instructions. GitHub’s current Linux installation guide also publishes both trusted fingerprints and uses /etc/apt/keyrings/githubcli-archive-keyring.gpg for Debian-family systems.[2][3]
Verify the result with GitHub’s recommended key inspection command:[2]
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg
Look for both fingerprints published by GitHub:[2][3]
Old: 2C6106201985B60E6C7AC87323F3D4EA75716059
New: 7F38BBB59D064DBCB3D84D725612B36462313325
Do not disable signature checking to make an update succeed. The safe fix is to install GitHub’s replacement keyring and confirm the new fingerprint against GitHub’s own documentation.[2][3]
Fedora, RHEL and CentOS fix
Check your DNF version first so you follow the matching GitHub instructions:[2]
dnf --version
DNF5 — Fedora 41 or newer
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 — RHEL, CentOS and Fedora 40 or earlier
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
When prompted to import a key, compare the fingerprint with 7F38BBB59D064DBCB3D84D725612B36462313325. GitHub tells RPM users to re-fetch the repository configuration so it references the updated keyring.[2]
Amazon Linux 2 fix
type -p yum-config-manager >/dev/null || sudo yum install yum-utils
sudo yum-config-manager --add-repo \
https://cli.github.com/packages/rpm/gh-cli.repo
sudo yum update gh
openSUSE and SUSE fix
sudo zypper removerepo gh-cli
sudo zypper addrepo https://cli.github.com/packages/rpm/gh-cli.repo
sudo zypper update gh
The package-manager-specific commands above are the remediation published by the GitHub CLI team.[2]
Docker and CI fix
A cached container layer can preserve the old key even when your current Dockerfile looks correct. Refresh the keyring before the next apt update or apt-get update:[2]
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
Then rebuild without reusing the stale layer that originally downloaded the key. GitHub specifically warns that Docker builds can fail when an older layer added the repository and a later layer runs APT with the outdated keyring.[2]
If the image does not use gh at all, GitHub says you can remove the unused GitHub CLI repository rather than weakening APT verification:[2]
RUN rm -f /etc/apt/sources.list.d/github-cli.list
Who is affected?
You should check or update if all three conditions from GitHub’s affected-systems table are true:[2]
- You use Linux.
- You installed
ghthrough GitHub’s official APT, DNF, YUM or Zypper repository. - The setup predates April 8, 2026, and the installation steps have not been rerun since.
GitHub says installations made from the official instructions after April 8 already contain the replacement key. Windows, macOS, Homebrew, Conda, community packages, direct release binaries and source builds do not use this affected repository key path.[1][2]
Errors this fixes
GitHub says an outdated keyring may produce messages such as these:[2]
EXPKEYSIG 23F3D4EA75716059 GitHub CLI
NO_PUBKEY 5612B36462313325
Signature verification failed
GPG check FAILED
These errors mean the package manager cannot validate repository metadata or a package with its currently trusted keys. GitHub lists these exact error patterns in the full rotation announcement.[2]
If the RPM error continues
Re-adding the repository should be the first fix. If signature errors continue, GitHub advises listing imported keys and inspecting only the GitHub CLI key package before removing anything:[2]
sudo rpm -qa gpg-pubkey
sudo rpm -qi gpg-pubkey-75716059-63172e8a
Confirm that the package information identifies GitHub CLI before deleting a key. GitHub’s recovery instructions provide key-removal steps, but removing the wrong system key can break verification for another repository, so do not match on a short ID alone.[2]
Frequently asked questions
Does the installed gh command stop working on September 5?
The announced impact is on package and repository signature verification. An already installed binary is not described as being remotely disabled; the practical risk is that future installs or updates through the affected APT or RPM repository can fail.[1][2]
Do I need to reinstall GitHub CLI?
Usually no. APT users can replace the local keyring, update package lists and install or upgrade gh. RPM users should re-fetch the repository configuration and update the package. Reinstallation is a later troubleshooting step if an old RPM key still causes verification errors.[2]
Is the new key fingerprint case-sensitive?
Hexadecimal fingerprints are commonly displayed in uppercase, but the important check is the full sequence: 7F38BBB59D064DBCB3D84D725612B36462313325. Compare all 40 characters with GitHub’s official documentation rather than trusting only the final eight or sixteen characters.[2][3]
What if I installed gh with Homebrew or Conda on Linux?
GitHub says this rotation does not affect Homebrew, Conda, community package managers, direct release binaries or source builds because those methods do not use the official APT/RPM repository signing key.[1][2]
Should I use --allow-unauthenticated or disable GPG checks?
No. That bypasses the protection the signing key provides. Replace the keyring from GitHub’s official HTTPS package URL, verify the full fingerprint, and keep package signature checking enabled.[2][3]