GitHub CLI’s Linux Signing Key Expired Today: Fix APT and RPM Before Your Next `gh` Update

Short answer: if you installed GitHub CLI (gh) from GitHub’s official APT or RPM repository before April 8, 2026 and never refreshed that repository setup, your next package update can fail because GitHub’s old PGP signing key expired on September 5, 2026.

GitHub already published a replacement key in April. Newer installs are normally fine. Windows, macOS, Homebrew, Conda, direct .deb files, standalone binaries, and source builds are not affected by this repository-key rotation.

Status check — September 5, 2026: GitHub says the old signing key expired at 2026-09-05T12:44:10Z. Beginning with the first GitHub CLI release after the expiry, APT/RPM repository metadata and newly published RPM packages are signed with the replacement key.

Why an installed gh can suddenly break during apt update

Package managers do not trust a repository merely because its URL uses HTTPS. They also verify repository metadata and packages against trusted signing keys.

GitHub CLI’s previous Linux repository key had this fingerprint:

2C6106201985B60E6C7AC87323F3D4EA75716059

The replacement key is:

7F38BBB59D064DBCB3D84D725612B36462313325

GitHub published a keyring containing both keys on April 8, 2026. Systems configured from the official instructions after that date generally already trust the replacement key. Older machines, cached images, long-lived CI runners, and Docker layers are the higher-risk group.

The failure may look like a GitHub CLI problem even when gh itself still runs. The package manager is what fails because it can no longer verify fresh repository metadata.

Typical symptoms include EXPKEYSIG, NO_PUBKEY, GPG check FAILED, or messages saying the repository metadata is signed by an unknown key.

Am I affected?

If you do not remember when the machine was configured, do not guess. Check the local keyring.

Debian and Ubuntu: verify before changing anything

GitHub recommends inspecting the keyring referenced by your APT source.

First try:

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

Older setups may use:

gpg --show-keys /usr/share/keyrings/githubcli-archive-keyring.gpg

If neither path exists, inspect the repository entry:

cat /etc/apt/sources.list.d/github-cli.list

Look for the signed-by= path. That tells you which keyring APT actually uses.

What a healthy keyring should contain

You want to see the replacement fingerprint:

7F38BBB59D064DBCB3D84D725612B36462313325

GitHub’s current keyring may show both the expired old key and the new key. That is fine. The important point is that the new key is present.

If only the old fingerprint appears, update the keyring.

Debian and Ubuntu: the APT fix

Using 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 using 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

One subtle failure mode is updating /etc/apt/keyrings/... while the repository entry still points to an older file under /usr/share/keyrings/. After updating, confirm the signed-by= value in /etc/apt/sources.list.d/github-cli.list points to the keyring you actually replaced.

Then verify again:

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

Fedora, RHEL, CentOS, Amazon Linux and SUSE

RPM-family systems import signing keys through their repository configuration, so GitHub’s recommended repair is to refresh the repo definition and then update gh.

Fedora 41+ with DNF5

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 older Fedora

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

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

When the package manager asks to import a signing key, verify the fingerprint rather than blindly accepting the prompt. The replacement fingerprint is:

7F38BBB59D064DBCB3D84D725612B36462313325

Docker and CI are where this can hide longest

A developer laptop tends to receive package changes regularly. A Docker image or CI base layer can quietly preserve repository configuration from months ago.

A common failure pattern is:

old base layer adds GitHub CLI repo + old key
        ↓
image remains cached for months
        ↓
later layer runs apt update
        ↓
repository signature verification fails

If you control the layer that installs GitHub CLI, rebuild it using the current official setup. If you do not, refresh the keyring before the next apt update:

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

If the image does not use gh at all, a cleaner fix may be to remove the stale GitHub CLI repository instead of keeping an unused package source alive.

Do not “fix” this by disabling signature verification

An expired signing key is annoying, but the verification failure is doing its job.

Avoid workarounds that mark the repository as trusted without verification, disable GPG checks, or globally weaken package-manager signature rules. Those approaches can restore an update command while removing the protection that tells you whether repository metadata came from the expected publisher.

The correct repair is to install and verify GitHub’s replacement key.

A five-minute fleet audit

For one laptop, the manual check is easy. For a team, the higher-value move is to find stale setup before developers and builds fail independently.

Search your infrastructure for:

cli.github.com/packages
23F3D4EA75716059
2C6106201985B60E6C7AC87323F3D4EA75716059
githubcli-archive-keyring.gpg
gh-cli.repo

Check these places first:

• Dockerfiles and base-image repositories;
• cloud-init and machine-bootstrap scripts;
• CI runner images;
• Ansible/Chef/Puppet/Salt configuration;
• developer-environment scripts;
• long-lived VM templates;
• documentation copied from old installation instructions.

A useful fleet rule is: the repository definition, its signing key, and the package are one configuration unit. Updating only gh is not enough when the trust metadata around its repository is stale.

Why this is worth fixing even if gh still works today

The current binary does not stop executing merely because a repository signing key expires. The failure appears when the system needs fresh signed repository metadata or a newly signed package.

That makes this the kind of maintenance bug that can sit invisible until a bad moment: a new CI image build, a production bootstrap, a developer onboarding script, or a security update that happens to run apt update first.

GitHub experienced a similar signing-key expiry in September 2024, when package installs and updates were disrupted. The 2026 replacement key was published months ahead of time specifically to make this rotation proactive rather than emergency maintenance.

Conclusion

If your Linux system uses GitHub’s official APT or RPM repository, the important question is not whether gh --version works. It is whether the package manager trusts GitHub’s replacement signing key.

For installs configured after April 8, 2026, the new key should already be present. For older machines and cached automation, verify the keyring now and refresh it if needed.

The clean test is simple: make sure fingerprint 7F38BBB59D064DBCB3D84D725612B36462313325 is trusted, then run the normal package update path successfully. Do that once in your reusable images and bootstrap scripts, and you avoid rediscovering the same expiry on every machine later.

Sources

Checked September 5, 2026:

• GitHub Changelog — GitHub CLI Linux package signing key expires September 5
• GitHub CLI — Full September 2026 PGP signing-key rotation announcement
• GitHub CLI — Official Linux installation instructions