GitHub CLI's Linux signing key expires, and one command fixes it

The PGP key that signs GitHub CLI Linux packages expires on 5 September 2026. GitHub confirmed the date in a changelog post on 3 September, five months after it first published the replacement key inside a combined keyring in April.

What changes on 5 September

GitHub says that from the first release after the expiry, both the APT and RPM repositories will publish metadata and packages signed only with the replacement key. Systems that never received that key from the April keyring will fail signature verification on the next install or update. On APT systems the error is EXPKEYSIG against the old fingerprint. On RPM systems it is a warning about an untrusted or expired key on the next dnf or yum transaction.

The replacement key fingerprint is 7F38BBB59D064DBCB3D84D725612B36462313325. GitHub linked the full rotation instructions from its changelog post to CLI repository issue #13118, where the maintainers give the APT keyring path at /etc/apt/keyrings/githubcli-archive-keyring.gpg and the RPM repo file at https://cli.github.com/packages/rpm/gh-cli.repo.

Who is affected and who is not

The change only affects the two package channels GitHub controls directly. If gh was installed through Homebrew, Conda, a community package on another distribution, a direct .deb download, or a standalone archive from GitHub Releases, nothing needs to change. Windows and macOS installers do not use this PGP key at all.

The group that has to act is the one running the official apt or dnf repository on Debian, Ubuntu, RHEL, Fedora, or their derivatives. That covers a large share of CI runners, base images, dev containers, and long-lived Linux workstations, and each of them tends to install gh non-interactively from a script, so an unattended signature failure often shows up as a broken build rather than a warning a human sees.

There are two working days between the changelog post and the expiry, which is enough time to check but only enough time to check. The first place to check is any image, Ansible role, Dockerfile, or bootstrap script that adds the GitHub CLI repository: those need to import the replacement keyring before they can install a new release. The second place is the machines already running, because a machine that installed gh months ago may still trust only the old key and will start failing the next time apt update runs.

GitHub says the replacement key has been available since April, so systems that received a keyring update in the last five months are likely fine already. The cost of confirming is a single gpg --list-keys or rpm -q gpg-pubkey check per host. The cost of not confirming is a class of build failure that is difficult to attribute without knowing the deadline exists.

Source

• GitHub CLI Linux package signing key expires September 5, GitHub Changelog, 3 September 2026
• Rotation instructions in cli/cli issue #13118, 8 April 2026