GitHub CLI's Linux Signing Key Expired September 5, 2026 — Who Breaks and How to Fix It

If you installed GitHub CLI on Linux with apt install gh or dnf install gh, this one is for you: GitHub’s changelog dated 2026-09-03 states that the signing key for the gh Linux package repositories expires on 2026-09-05.

The short version: most people do not have to do anything, but one specific group will hit signature errors on their next update. Here is how to tell which group you are in.

1. What this actually means

Package managers (APT, RPM) verify downloads against a public key to confirm the package really came from GitHub and was not swapped in transit. That is the mechanism that stops someone slipping a fake package into your update.

Keys have expiry dates. GitHub’s expires on September 5, which is why they published a replacement keyring back in April 2026 containing both the current key and its replacement.

Per the announcement: beginning with the first release after that date, APT and RPM repository metadata and newly published RPM packages will be signed with just the replacement key.

If your machine only trusts the old key, the metadata it downloads afterwards will not verify.

2. Who needs to act, and who does not

You need to act if you installed GitHub CLI from the official APT or RPM repositories before 2026-04-08 and have not updated your setup since. Those machines likely trust only the old key.

Explicitly unaffected, per GitHub:

• Windows users
• macOS users
• Anyone building from source
• Anyone installing via Homebrew, Conda, or community package managers
• Anyone using direct .deb files or standalone binaries from GitHub Releases

So this only touches one installation path: the official apt/rpm repositories.

3. How to check whether you are affected

Run an update and watch for verification errors. On Debian/Ubuntu:

sudo apt update

Messages like “NO_PUBKEY”, “signatures couldn’t be verified”, or “key has expired” pointing at the GitHub CLI repository mean you are in the affected group.

For the actual key rotation commands, follow GitHub’s own announcement. It carries the correct key location and fingerprint as of today. Copying key-trust commands from a third-party blog post is exactly how people end up trusting a stale or wrong source — which is why this article deliberately does not invent a command sequence for you.

4. What happens if you ignore it

Nothing breaks immediately. Your installed gh binary keeps working.

The real consequences are:

1. apt update starts erroring on that repository, and many update scripts abort entirely when a single source fails, taking your other package updates down with it.
2. You stop receiving new gh releases, including future security fixes.
3. On CI and servers this typically surfaces as “the pipeline went red one morning” — usually while you are busy with something else.

5. Our take: routine key rotation, and the risk is in the stale machines

Key expiry is by design, not an incident. GitHub’s handling was textbook: publish a keyring containing both keys roughly five months ahead (April) so that machines updating normally rotate without anyone noticing.

The machines that break are the ones nobody has touched since install — the two-year-old build server, the base image, the container nobody wants to open. Those are exactly the machines most companies have the most of.

Practical advice: do not just fix your laptop. Grep your Dockerfiles, Ansible/Puppet configs and CI images for a hardcoded GitHub CLI repository key. Those are the places that will fail quietly after September 5.

Source: GitHub Changelog, 2026-09-03, verified 2026-09-07. Use the official announcement for the actual rotation commands. Our plan and pricing record for GitHub Copilot lives on the GitHub Copilot tool page.