GitHub CLI's Linux signing key expires today; apt and dnf break
After today, gh installs via APT and RPM fail with EXPKEYSIG errors until you pull the new keyring — one command per manager. macOS and Homebrew are safe.
Copy markdown
What breaks, and when
The PGP key signing GitHub CLI's APT (Debian/Ubuntu) and RPM (Fedora/RHEL) repos — fingerprint 2C61…6059 — expires September 5. After that, `apt update` and `dnf update` throw `EXPKEYSIG 23F3D4EA75716059` or 'Signature verification failed' and refuse to install or upgrade `gh`.
The APT fix (Debian/Ubuntu)
Re-fetch the keyring and you're clear: `sudo wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg`, then `sudo apt update`. The replacement key (7F38…3325) shipped next to the old one back in April, so this is a one-time catch-up.
The RPM fix (Fedora/RHEL)
On DNF5 (Fedora 41+): `sudo dnf config-manager addrepo --overwrite --from-repofile=https://cli.github.com/packages/rpm/gh-cli.repo`, then `sudo dnf update gh`. DNF4, Yum and Zypper run the equivalent config-manager command against the same repo file.
Who can ignore this
macOS, Homebrew, Conda, Windows, source builds, standalone binaries and direct .deb downloads are untouched — only the APT/RPM repos are re-signed. If you added or refreshed the keyring after April 8, you already trust the new key.
Harden your CI before it bites
Docker images and CI runners that register GitHub's apt/rpm repo will start failing builds today too. Bake the keyring fetch into the image, or pin gh's standalone binary, so the next key rotation never breaks a pipeline.
Elsewhere: a privacy-safe star-history API
GitHub also shipped a REST endpoint that returns a repo's star count over time without exposing individual stargazers — clean data for growth charts and trend dashboards, no scraping required.