gh Suddenly Won't Update on Linux? The GitHub CLI Signing Key Expired September 5 — Fix It on apt, dnf, yum and zypper

If you installed GitHub’s gh command on Linux through apt or dnf, today (September 5, 2026) matters: the PGP key that signs GitHub CLI’s Linux packages expires today.

From the first release after that date, repository metadata and newly published RPM packages are signed with the replacement key alone. Systems still carrying only the old key will start failing on apt update or dnf update.

The good news: GitHub prepared this half a year ahead — a keyring containing both the old and the new key was published on April 8, 2026. Many people are already covered without doing anything.

First: are you actually affected?

The official announcement gives a table. In plain language:

Check it yourself with one command

Debian / Ubuntu (apt)

gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpg

(If the file is not there, try /usr/share/keyrings/githubcli-archive-keyring.gpg; if you still cannot find it, run cat /etc/apt/sources.list.d/github-cli.list and look at the signed-by= path.)

Reading the result: two public keys means you are fine; one (the old key) means you need to update. The fingerprints are:

• Old key (expires 2026-09-05): 2C6106201985B60E6C7AC87323F3D4EA75716059
• New key: 7F38BBB59D064DBCB3D84D725612B36462313325

Fedora / RHEL / CentOS / openSUSE / Amazon Linux 2 (rpm)

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

One entry only (the old key) means you need to update; a second entry means the new key is already imported.

The fix

Debian / Ubuntu

Replace the keyring file with the current official one, then update:

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

No wget? Swap that download line for curl -fsSL -o with the same paths.

If your keyring lives elsewhere (for example under /usr/share/keyrings/), update the path above accordingly and make sure the signed-by= field in your APT source entry points at the same file.

Docker build failing? Put the same download command in a RUN line in your Dockerfile (inside a container you are usually root already, so drop sudo).

Not actually using gh — it just happens to be in a base image? Remove the repository so apt update stops verifying it:

sudo rm /etc/apt/sources.list.d/github-cli.list

Fedora 41 or newer (DNF5)

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

CentOS / RHEL / Fedora 40 or earlier (DNF4)

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

openSUSE / SUSE (zypper)

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

RPM systems will prompt you to confirm importing the keys during the final upgrade. Compare the fingerprints against the two strings above before accepting. Do not skip this — verifying the fingerprint is the entire point of package signing.

Still failing? Remove the old key from the RPM keyring first

sudo rpm -qa gpg-pubkey
sudo rpm -qi gpg-pubkey-75716059-63172e8a

Confirm the Packager field reads GitHub CLI <[email protected]>, then remove it and reinstall:

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

(Substitute yum or zypper as appropriate.)

What the errors look like

The announcement lists typical messages. Any of these points at this issue:

W: Failed to fetch https://cli.github.com/packages/dists/stable/InRelease
The following signatures were invalid: EXPKEYSIG 23F3D4EA75716059 GitHub CLI
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5612B36462313325

Transaction failed: Signature verification failed.
OpenPGP check for package ... from repo "gh-cli" has failed

Error: GPG check FAILED

Why this happens at all

Package repositories are signed with PGP keys so your machine can confirm a file really came from GitHub and was not swapped in transit. Keys have expiry dates, and expiry means rotation.

The last time GitHub’s key expired (September 2024) it was patched by extending the old key as an emergency fix, and plenty of installs and updates broke. This time the project rotated to a brand-new key half a year early and shipped both keys together — which is why anyone who installed recently from the official docs has nothing to do.

FAQ

I see no errors today. Am I safe?

Not necessarily. The official wording is that the change begins with the first release after the expiry date. You may be fine today and break next week. Rather than wait for it, run the one-line check above.

I installed gh with Homebrew. Do I need to act?

No. Homebrew, Conda, community packages, .deb files and standalone binaries from GitHub Releases do not use this PGP key.

Is this a security incident? Was my machine compromised?

No on both counts. This is routine key rotation, not a breach. The genuine risk here is the opposite move: if you silence the error by disabling signature verification, you have traded a small chore for a real exposure. Install the new key instead of turning off the check.

Sources: GitHub CLI announcement issue #13118, “Upcoming PGP signing key rotation for GitHub CLI Linux packages [September 2026]” (published 2026-04-08, containing the self-check steps, per-package-manager fixes, key fingerprints and sample errors), and the GitHub changelog entry “GitHub CLI Linux package signing key expires September 5” (2026-09-03). Both read directly on 2026-09-05. Evidence level: first-party, cross-checked across two official pages. More: GitHub Copilot tool page, Copilot content exclusion guide