GitHub is warning Linux users of GitHub CLI signing key changes for the official package repositories. The current PGP key used for GitHub CLI Linux package repositories expires on Saturday, September 5, 2026, and that affects how repository metadata and packages are signed going forward.

The practical issue is not that GitHub CLI stops working on that date. Instead, the signing setup for APT and RPM package sources is changing, and some systems may need to trust the replacement key before the next release cycle. GitHub says that beginning with the first release after September 5, repository metadata and newly published RPM packages will be signed with only the replacement key.

GitHub CLI Signing Key Changes For Linux Users

GitHub says it published a keyring in April that includes both the current key and the replacement key. That gives maintainers and users a transition period to move systems over before the older key expires. The company’s guidance is aimed at keeping package verification intact when the signing switch happens.

For readers, the main takeaway is that package trust settings matter as much as the software itself. If a system still expects the older key after the transition, package updates from the official GitHub CLI repositories may fail verification or require manual intervention. That is especially relevant for machines managed at scale, where a single outdated configuration can affect many devices at once.

Who Needs To Act Before The Deadline

GitHub identifies one specific group that should pay close attention: people who installed gh from the official APT or RPM repositories before April 8, 2026, and have not updated the setup since then. Those users are being told to follow the instructions in the full announcement before September 5.

GitHub also says that if you installed GitHub CLI later, are not sure when you set it up, or rely on a custom image or automation path, you should review the announcement steps to verify that your system trusts the replacement key. That advice matters because package installation history is not always obvious, especially in images, scripts, and automated deployments that may have been built long before the current environment.

In other words, the risk is less about the expiration itself and more about lingering configuration. A system may appear healthy until a package update attempts to verify against the new signing arrangement.

Why The GitHub CLI Signing Key Matters

Package signing keys are a core part of Linux software distribution. They help users confirm that a package or repository metadata really came from the expected source and has not been altered in transit. When a key expires and a replacement becomes authoritative, admins need to make sure their verification path is updated too.

For GitHub CLI users, this is a reminder that trusted installation sources require ongoing maintenance. A one-time setup is not always enough, particularly for command-line tools that are installed through system package managers and later refreshed automatically. The update window GitHub described is designed to reduce disruption, but it still depends on users and operators taking action in time.

The announcement is also a useful signal for teams that manage developer workstations and container images. If those environments use the official GitHub CLI repositories, they should be checked now rather than after the deadline, because expired signing keys can create avoidable friction during routine updates.

What To Watch Next

Users should watch for GitHub’s full announcement and follow the repository trust update steps if their systems match the affected setup. The key date is September 5, 2026, after which the new signing arrangement begins for the next release.

For teams, the next practical step is to audit how GitHub CLI signing key trust is handled across laptops, build images, and automation. Systems configured with the April keyring may already be ready, but older setups may need manual updates before the old key expires.

If your environment depends on the official APT or RPM repositories, this is a good time to confirm that package verification will continue without interruption. The change is straightforward, but the deadline is fixed.

Explore AI Craft Pad

Practical AI articles · AI tools · Step-by-step guides