You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue only affects Linux users who install gh from our APT or RPM package repositories. If you are on Windows or macOS, or you installed gh via Homebrew, GitHub Releases, or built from source code, this does not apply to you.
The PGP key currently used to verify GitHub CLI Linux packages is expiring on Saturday, September 5, 2026. We have generated a new key and have already published an updated keyring file that contains both the old and new keys on Wednesday, April 8, 2026. This table lists the current and the new PGP key fingerprint:
Key
Fingerprint
Current key (expires September 5, 2026)
2C6106201985B60E6C7AC87323F3D4EA75716059
New key
7F38BBB59D064DBCB3D84D725612B36462313325
As a background, back in September 2024, our PGP signing key expired (#9569), disrupting Linux package installs and updates. At that time, we extended the expiration of the existing key as an emergency fix. This time, however, we are proactively rotating to a brand-new key well ahead of the expiry date.
Check out Am I affected? below to see if you are going to be affected by this change. For affected users, package install and update operations that rely on the old key will start failing after the expiry date unless you follow the steps outlined in this document. Typical error/warning messages look like any of the following:
W: Failed to fetch https://cli.github.com/packages/dists/stable/InRelease The following signatures were invalid: EXPKEYSIG 23F3D4EA75716059 GitHub CLI <opensource+cli@github.com> The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5612B36462313325
Transaction failed: Signature verification failed.
OpenPGP check for package ... from repo "gh-cli" has failed: Import of the key didn't help, wrong key?
The GPG keys listed for the "packages for the GitHub CLI" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.. Failing package is: gh...
GPG Keys are configured as: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x23F3D4EA75716059
...
Error: GPG check FAILED
The GPG keys listed for the "packages for the GitHub CLI" repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: gh...
GPG Keys are configured as: https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x23F3D4EA75716059
Warning: File 'repomd.xml' from repository 'packages for the GitHub CLI' is signed with an unknown key '5612B36462313325'
...
Warning: We can't verify that no one meddled with this file, so it might not be
trustworthy anymore! You should not continue unless you know it's safe.
...
Repository 'packages for the GitHub CLI' is invalid.
[gh-cli|https://cli.github.com/packages/rpm] Valid metadata not found at specified URL
History:
- Signature verification failed for repomd.xml
- Can't provide /repodata/repomd.xml
gh-... (packages for the GitHub CLI): Signature verification failed [4-Signatures public key is not available]
Warning: File 'repomd.xml' from repository 'packages for the GitHub CLI' is signed with an unknown key '5612B36462313325'
...
Warning: We can't verify that no one meddled with this file, so it might not be
trustworthy anymore! You should not continue unless you know it's safe.
...
Repository 'packages for the GitHub CLI' is invalid.
[gh-cli|https://cli.github.com/packages/rpm] Failed to retrieve new repository metadata.
History:
- Signature verification failed for repomd.xml
error: Verifying a signature using certificate 2C6106201985B60E6C7AC87323F3D4EA75716059 (GitHub CLI <opensource+cli@github.com>):
1. Certificate 23F3D4EA75716059 invalid: certificate is not alive
because: The primary key is not live
because: Expired on 2026-09-05T12:44:10Z
2. Key 23F3D4EA75716059 invalid: key is not alive
because: The primary key is not live
because: Expired on 2026-09-05T12:44:10Z
If you do not remember when you installed gh from the official docs, you can easily confirm if you are going to be affected by checking your local configuration. Follow the subsection that applies to you.
If you still cannot find the keyring file, check your APT source entry to see the path it references:
cat /etc/apt/sources.list.d/github-cli.list
Look for the signed-by= value in the output, which points to your keyring file path.
If the output shows two public key entries (with fingerprints 2C6106201985B60E6C7AC87323F3D4EA75716059 and 7F38BBB59D064DBCB3D84D725612B36462313325), you already have the updated keyring and no action is needed. This is what the output should look like:
If you are installing gh for the first time, simply follow the standard Linux installation instructions. The current keyring file already contains the new key, so no extra steps are needed. This also applies if you installed gh for the first time after the new keyring was published (April 8, 2026).
If your keyring file is located elsewhere (e.g., under /usr/share/keyrings/), you should update that path in the command above. However, the recommended location is /etc/apt/keyrings/. Regardless of the path, make sure the signed-by field in the APT source entry (at /etc/apt/sources.list.d/github-cli.list) points at the right keyring file.
Tip
You can verify the updated keyring contains both keys by running:
If your Docker build is failing because a layer previously added our package repository and a later layer runs apt update or apt-get update, you need to ensure the updated keyring is present.
If you control the layer that adds the keyring, rebuild it so it pulls the latest keyring file.
If you don't control that layer, add a new layer before any apt update or apt-get update that fetches the updated keyring:
RUN wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \
&& chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
If you don't use gh at all and it just happens to be in a base image, you can remove the repository so that apt update or apt-get update no longer try to verify it:
RPM-based systems import PGP keys into their own keyring at install time. To pick up the new key, you need to re-fetch the repository configuration file, which now references an updated keyring. Choose the instructions matching your package manager below.
Note that when upgrading gh at the end, your package manager will prompt you to confirm importing the PGP keys. Verify that the key fingerprints match the following:
Old key: 2C6106201985B60E6C7AC87323F3D4EA75716059
New key: 7F38BBB59D064DBCB3D84D725612B36462313325
Important
Instructions below mimic our Linux installation guide. So, please make sure you follow the heading that you originally used to install gh.
If you still encounter key verification errors after re-adding the repository, you may need to remove the old key from the RPM keyring first:
Find the old PGP key:
sudo rpm -qa gpg-pubkey
Our old PGP key is usually named gpg-pubkey-75716059-63172e8a or gpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8a. You can confirm the correct key by checking its Packager field:
sudo rpm -qi gpg-pubkey-75716059-63172e8a
# or
sudo rpm -qi gpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8a
The Packager should be GitHub CLI <opensource+cli@github.com>.
Once you have confirmed the Packager, remove the old PGP key:
sudo rpm -e gpg-pubkey-75716059-63172e8a
# or
sudo rpm -e gpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8a
In September 2024, our PGP signing key expired (#9569), disrupting Linux package installs and updates. At that time, we extended the expiration of the existing key as an emergency fix.
This time, we are proactively rotating to a brand-new key well ahead of the expiry date. The updated keyring files (binary .gpg and ASCII armored .asc) already contain both the old and new keys, so anyone who has installed gh following our Linux installation instructions since April 8, 2026, is already covered.
We apologize for any inconvenience this may cause. By announcing well in advance, we hope to give everyone enough time to update their keyring before the old key expires.
If you run into any problems, please follow up on this issue and we'll do our best to help.
Thank you for your patience and for using GitHub CLI!
Note
This issue only affects Linux users who install
ghfrom our APT or RPM package repositories. If you are on Windows or macOS, or you installedghvia Homebrew, GitHub Releases, or built from source code, this does not apply to you.What's happening?
The PGP key currently used to verify GitHub CLI Linux packages is expiring on Saturday, September 5, 2026. We have generated a new key and have already published an updated keyring file that contains both the old and new keys on Wednesday, April 8, 2026. This table lists the current and the new PGP key fingerprint:
2C6106201985B60E6C7AC87323F3D4EA757160597F38BBB59D064DBCB3D84D725612B36462313325As a background, back in September 2024, our PGP signing key expired (#9569), disrupting Linux package installs and updates. At that time, we extended the expiration of the existing key as an emergency fix. This time, however, we are proactively rotating to a brand-new key well ahead of the expiry date.
Check out Am I affected? below to see if you are going to be affected by this change. For affected users, package install and update operations that rely on the old key will start failing after the expiry date unless you follow the steps outlined in this document. Typical error/warning messages look like any of the following:
Am I affected?
ghghviaaptbefore the new keyring was published (April 8, 2026) and haven't re-run the installation steps sinceghviadnf,yum, orzypperbefore the new keyring was published (April 8, 2026) and haven't re-run the installation steps sinceghusing official docs after the new keyring was published (April 8, 2026)ghvia Homebrew, Conda, a community package manager, or from precompiled binariesghHow to confirm locally installed keyring?
If you do not remember when you installed
ghfrom the official docs, you can easily confirm if you are going to be affected by checking your local configuration. Follow the subsection that applies to you.Debian/Ubuntu
Tip
If
gpgis not installed, you can install it with:Check how many keys are in your local keyring file:
Tip
If the file is not found at that path, try the older location:
If you still cannot find the keyring file, check your APT source entry to see the path it references:
Look for the
signed-by=value in the output, which points to your keyring file path.If the output shows two public key entries (with fingerprints
2C6106201985B60E6C7AC87323F3D4EA75716059and7F38BBB59D064DBCB3D84D725612B36462313325), you already have the updated keyring and no action is needed. This is what the output should look like:If only one key is listed (the old key
2C6106201985B60E6C7AC87323F3D4EA75716059), you need to update your keyring. See Existing APT users.RHEL/Fedora/CentOS/openSUSE/SUSE/Amazon Linux 2
Check which GitHub CLI keys are imported in your RPM keyring:
If the output includes only one entry (the old key), you will need to update. See Existing RPM users.
If you see a second key entry, your system already has the new key and no action is needed.
What do I need to do?
New users
If you are installing
ghfor the first time, simply follow the standard Linux installation instructions. The current keyring file already contains the new key, so no extra steps are needed. This also applies if you installedghfor the first time after the new keyring was published (April 8, 2026).Existing APT users (Debian/Ubuntu)
You need to replace your local copy of the keyring file. Run either of the following commands to download the updated keyring:
Then update your package lists and upgrade
gh:Note
If your keyring file is located elsewhere (e.g., under
/usr/share/keyrings/), you should update that path in the command above. However, the recommended location is/etc/apt/keyrings/. Regardless of the path, make sure thesigned-byfield in the APT source entry (at/etc/apt/sources.list.d/github-cli.list) points at the right keyring file.Tip
You can verify the updated keyring contains both keys by running:
You should see an output like this:
Docker build failing?
If your Docker build is failing because a layer previously added our package repository and a later layer runs
apt updateorapt-get update, you need to ensure the updated keyring is present.If you control the layer that adds the keyring, rebuild it so it pulls the latest keyring file.
If you don't control that layer, add a new layer before any
apt updateorapt-get updatethat fetches the updated keyring:RUN wget -qO /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \ && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpgOr if you prefer using
curl:RUN curl -fsSL -o /etc/apt/keyrings/githubcli-archive-keyring.gpg https://cli.github.com/packages/githubcli-archive-keyring.gpg \ && chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpgIf you don't use
ghat all and it just happens to be in a base image, you can remove the repository so thatapt updateorapt-get updateno longer try to verify it:Existing RPM users (Fedora, RHEL, CentOS, Amazon Linux 2, openSUSE/SUSE)
RPM-based systems import PGP keys into their own keyring at install time. To pick up the new key, you need to re-fetch the repository configuration file, which now references an updated keyring. Choose the instructions matching your package manager below.
Note that when upgrading
ghat the end, your package manager will prompt you to confirm importing the PGP keys. Verify that the key fingerprints match the following:2C6106201985B60E6C7AC87323F3D4EA757160597F38BBB59D064DBCB3D84D725612B36462313325Important
Instructions below mimic our Linux installation guide. So, please make sure you follow the heading that you originally used to install
gh.DNF5 (Fedora 41 or newer)
Tip
Run
dnf --versionif you are unsure what version you are using.Note
Ensure the
config-managerplugin is installed (for example,sudo dnf install dnf5-plugins).DNF4 (CentOS, RHEL, Fedora 40 or earlier)
Tip
Run
dnf --versionif you are unsure what version you are using.Note
Ensure the
config-managerplugin is installed (for example,sudo dnf install 'dnf-command(config-manager)').Yum (Amazon Linux 2)
Note
Ensure the
config-managerplugin is installed (for example,sudo yum install yum-utils).Zypper (openSUSE/SUSE)
Removing old key from RPM keyrings
If you still encounter key verification errors after re-adding the repository, you may need to remove the old key from the RPM keyring first:
Find the old PGP key:
Our old PGP key is usually named
gpg-pubkey-75716059-63172e8aorgpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8a. You can confirm the correct key by checking its Packager field:sudo rpm -qi gpg-pubkey-75716059-63172e8a # or sudo rpm -qi gpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8aThe Packager should be
GitHub CLI <opensource+cli@github.com>.Once you have confirmed the Packager, remove the old PGP key:
sudo rpm -e gpg-pubkey-75716059-63172e8a # or sudo rpm -e gpg-pubkey-2c6106201985b60e6c7ac87323f3d4ea75716059-63172e8aThen remove and reinstall
gh:(Replace
dnfwithyumorzypperas appropriate.)Background
In September 2024, our PGP signing key expired (#9569), disrupting Linux package installs and updates. At that time, we extended the expiration of the existing key as an emergency fix.
This time, we are proactively rotating to a brand-new key well ahead of the expiry date. The updated keyring files (binary
.gpgand ASCII armored.asc) already contain both the old and new keys, so anyone who has installedghfollowing our Linux installation instructions since April 8, 2026, is already covered.Final notes
We apologize for any inconvenience this may cause. By announcing well in advance, we hope to give everyone enough time to update their keyring before the old key expires.
If you run into any problems, please follow up on this issue and we'll do our best to help.
Thank you for your patience and for using GitHub CLI!