Some outages announce themselves. This one shows up as a wall of “signature verification failed” errors in a pipeline log, on a step nobody has touched in months, for a tool that was working fine yesterday.

What broke and why

GitHub rotated the PGP key used to sign its Linux APT and RPM package repositories for the gh CLI. The old key, fingerprint 2C6106201985B60E6C7AC87323F3D4EA75716059, expired on 5 September 2026. From the first release published after that date, repository metadata and new packages are signed only with the replacement key. GitHub published a keyring containing both keys back in April, giving anyone paying attention a five-month window to update. Most people were not paying attention, because a key rotation five months out does not feel urgent until the old key actually lapses.

The practical effect: any Debian or Ubuntu system whose APT keyring, or any RHEL, Fedora, Amazon Linux or openSUSE system whose RPM repo configuration, still only trusts the old key will now fail to install or update gh. That includes base container images pinned before April, golden AMIs baked once and reused since, and any CI runner image that installs the CLI fresh on every job rather than baking it in.

Who is actually affected

Not everyone. GitHub is explicit that this only touches installations from the official APT or RPM repositories. Windows and macOS users are unaffected, as are people building from source or installing through Homebrew, Conda, a distribution’s own community package, direct .deb downloads, or the standalone archive binaries published on GitHub Releases. If your pipelines install gh through one of those paths, this is not your problem today.

If you installed gh from GitHub’s own Linux repositories after 8 April 2026, your system likely already trusts both keys and needs no action. The exposure sits with anyone who set up the repository before that date and has not touched it since, and with anyone who genuinely does not know which path their infrastructure took, which in practice is a lot of European engineering teams running standardised images built by a platform team a year or more ago.

The fix

Debian and Ubuntu (APT):

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

RPM-based systems, using the package manager that matches your distribution (dnf config-manager addrepo --overwrite --from-repofile=... on DNF5, dnf config-manager --add-repo on DNF4, yum-config-manager --add-repo on Amazon Linux 2, or removing and re-adding the repo with zypper on openSUSE) against https://cli.github.com/packages/rpm/gh-cli.repo.

The wider lesson for European DevOps teams

This is a small incident on its own, but it is a useful stress test for a question worth asking before it is forced on you: does your organisation know, for every tool your build and deployment pipelines depend on, which of those tools sit behind a signing key with an expiry date, and who owns rotating trust for it before that date arrives? A gh install failing is an annoyance you fix in an afternoon. The same class of problem hitting a container registry credential, an internal artifact signing key, or a certificate your deployment pipeline depends on is an outage that reaches production.

If a five-month-old changelog entry can still catch pipelines out, it is worth an honest audit of what else in your CI/CD chain is one expired key away from a bad morning. If you want help building that inventory, or hardening your pipelines against supply chain and trust-anchor failures like this one before they hit you mid-deploy, contact Excello Digital. We help European engineering teams find the quiet single points of failure in their DevOps tooling before an expiry date finds them first.