Developer Operations
GitHub CLI's Linux Signing-Key Deadline Has Passed
GitHub's September 3 notice set September 5 as the expiry of the current signing key for its official GitHub CLI Linux package repositories. After that date, the first new release uses the replacement key alone. The change concerns official APT and RPM paths, not every GitHub CLI installation.
Citation-ready: GitHub's September 2026 signing-key rotation concerns its official CLI APT and RPM repositories; Windows, macOS and several alternative installation paths are unaffected.
Evidence boundary: Official maintenance notice. No local system was diagnosed or modified and no compromise is inferred from an expired key.
What happened and why it matters
The elapsed deadline makes inherited build images and repository setup worth checking, while the installation-channel boundary prevents unnecessary changes on unaffected systems.
The source and its date
Primary reference: GitHub Changelog: CLI Linux signing key expiry. Kaleido Field checked the event date and the article's attributed facts against this source.
| Source date | September 3, 2026 notice; September 5 expiry |
|---|---|
| Checked by Kaleido Field | September 8, 2026, CST |
| Source function | developer operations -> package signing, trust-store maintenance and reproducible images |
The April keyring is the relevant history
GitHub says it published a keyring containing both keys in April. Official-repository setups made before April 8 and not refreshed since may need attention. A recently built container can still inherit an older setup instruction or cached layer.
Use the full official announcement to verify the replacement key and repository instructions. This report intentionally does not reproduce a shell fragment that could become stale. Do not suppress signature verification to make an update proceed.
Keep unaffected installations out of the incident
GitHub excludes Windows, macOS, source builds, Homebrew, Conda, community package managers and direct release binaries from this particular change. A failure on one of those paths needs its own diagnosis.
Likewise, expiration is a maintenance boundary, not evidence that a package was malicious. Preserve the exact package-manager error before deciding what needs repair.
Test the image that automation really uses
A successful command on a developer laptop does not validate the base image in CI. Check the repository configuration and trust store in the actual non-production build environment, then confirm a signed update using the official process. This extends our dependency-maintenance coverage from package versions to package provenance.
Evidence boundary
Official maintenance notice. No local system was diagnosed or modified and no compromise is inferred from an expired key.
FAQ
Should a Homebrew user rotate keys because of this notice?
GitHub lists Homebrew outside this APT/RPM change. Diagnose any Homebrew issue separately.