GitHub CLI’s Linux Key Expires Now—Verify Images Before the Next Build

GitHub CLI’s old Linux repository signing key expired on September 5, 2026, according to GitHub’s September 3 notice. Beginning with the first release after the expiry, GitHub will use only the replacement key for APT and RPM repository metadata and for newly published RPM packages.

An independent GitHub release tracker also records the deadline and the switch to replacement-only signatures. The change does not stop an installed gh binary from running, but an APT or RPM environment that trusts only the expired key can no longer authenticate later repository refreshes, installations or upgrades.

Use the installation method to decide whether to investigate

The installed gh version is not the deciding factor. The relevant credential belongs to the package-manager configuration, so a working binary does not prove that its repository trust path is ready for the next update.

1. Homebrew, Conda, source or standalone binary: this rotation does not apply. Windows, macOS, community packages and direct Debian package downloads are also outside the affected repository path.
2. Official APT or RPM repository, refreshed after the replacement keyring appeared: the environment should already contain the new key, but inherited images and automation still merit inspection.
3. Official repository configured earlier and never refreshed: treat the environment as affected until the replacement key is visible locally.
4. Installation date unknown: inspect the active APT keyring or RPM key database rather than relying on file timestamps or gh --version.

The GitHub CLI rotation announcement identifies the expired fingerprint as 2C6106201985B60E6C7AC87323F3D4EA75716059 and its replacement as 7F38BBB59D064DBCB3D84D725612B36462313325. Compare the complete fingerprint, not merely the replacement key ID ending in 62313325; the same announcement documents EXPKEYSIG 23F3D4EA75716059 and NO_PUBKEY 5612B36462313325 among the expected APT failures.

APT users must update the keyring named by signed-by

On Debian or Ubuntu, first read /etc/apt/sources.list.d/github-cli.list and locate its signed-by= value. Inspect that exact file with gpg --show-keys; common locations are /etc/apt/keyrings/githubcli-archive-keyring.gpg and the older /usr/share/keyrings/githubcli-archive-keyring.gpg.

If the active keyring contains only the expired fingerprint, replace that file with the current keyring from https://cli.github.com/packages/githubcli-archive-keyring.gpg. GitHub’s current Linux installation procedure creates /etc/apt/keyrings, downloads the keyring there, makes it readable with chmod go+r, and configures the repository entry to reference it.

Where an existing source entry points elsewhere, update the referenced file or deliberately change signed-by to the new location. Refresh metadata with sudo apt update, then install or upgrade with sudo apt install gh. Do not bypass the failure with an unauthenticated-package option: that removes the verification the replacement key is meant to restore.

RPM environments must re-fetch the repository definition

Fedora, RHEL, CentOS, Amazon Linux and openSUSE/SUSE import repository keys into the RPM database. List gpg-pubkey packages, inspect their metadata and identify GitHub CLI entries by the Packager value GitHub CLI <[email protected]>. If only the old fingerprint is represented, the replacement key still needs to be imported.

Re-fetch the gh-cli.repo definition using the configuration command appropriate to the installed manager: dnf config-manager, yum-config-manager or zypper. DNF installations should check dnf --version before choosing between the available config-manager syntaxes; Zypper environments should remove and re-add the named repository before refreshing gh.

During the next package operation, verify that the proposed import matches the complete replacement fingerprint recorded above. If verification continues to fail, confirm the Packager field before removing an old gpg-pubkey package. A short key ID alone is not a safe deletion criterion because it does not establish which repository owns the record.

Inspect containers and automation inside the resulting image

A current Dockerfile is not proof of current trust material. A base image or cached layer may still contain the old keyring, while a later layer runs apt update or an RPM metadata refresh against that stored configuration. The decisive evidence is the key visible inside the built artifact.

Start a disposable container from the final image and repeat the relevant APT or RPM inspection there. If the replacement key is absent, fetch the current keyring before the first repository refresh and rebuild without reusing the stale key-download layer. When an inherited image does not use gh, removing its dormant GitHub CLI repository entry prevents unrelated package refreshes from depending on that repository.

Apply the same check to bootstrap scripts, configuration-management roles, golden-image pipelines and internal templates. A bundled keyring, pinned old fingerprint or script that recreates an obsolete repository definition can reverse a manual repair during the next rebuild.

Make the repaired trust path reproducible

After remediation, inspect the active configuration again. APT must expose the complete replacement fingerprint through the keyring referenced by signed-by; RPM-family systems must expose it through the imported-key records associated with GitHub CLI. Then perform a normal metadata refresh and gh installation or upgrade with signature checking enabled.

For maintained CI images, turn that fingerprint comparison into a build assertion and run it separately for every distribution-specific artifact. The expiry is now fixed; the remaining trigger is the first subsequent GitHub CLI release using replacement-only signatures, which will expose any stale trust configuration as a package-verification failure.

Also read:

• Corporate Blogs Still Build Brands—but Only When They Earn Trust
• Cold Outreach Can Fail Before the Pitch: Fix the Gatekeepers First
• The Rent Is Only the Start: Plan Your Retail Space Before You Sign