Beyond the News
Sign in
Web DevelopmentDeveloper Tools Active dossier

GitHub CLI’s Linux package signing key expires September 5

GitHub CLI users who install `gh` through apt, yum or dnf need GitHub’s replacement package-signing keyring before September 5 unless they have already refreshed their repository setup since April.

Reviewed and published by Lars Jansen Updated 4 min read
Comment
First published

Key details

  1. The old GitHub CLI Linux package signing key expires September 5, 2026.
  2. GitHub published a replacement keyring on April 8 containing both the current and replacement keys.
  3. Users who reran GitHub’s Linux installation steps after the new keyring appeared are already covered.
  4. Affected package managers are apt, yum and dnf.
  5. The issue concerns future package verification/updates rather than the continued execution of an already-installed `gh` binary.
  6. Windows, macOS, Homebrew, Conda, source builds and precompiled binaries are unaffected by this key rollover.

What builders should take away

  1. Check how `gh` is installed in developer images, CI runners and long-lived Linux hosts before the September 5 cutoff.
  2. Refresh GitHub’s repository/keyring setup using the current official distro instructions rather than copying a key from an old internal script.
  3. Update base images and bootstrap scripts as well as individual machines so a rebuilt environment does not reintroduce the expired key.
  4. Do not treat a working `gh --version` as proof that the package repository is healthy; test the package-manager metadata/update path.

What changed

GitHub’s existing PGP signing key for GitHub CLI Linux package repositories expires on September 5, 2026. GitHub published a replacement keyring in April containing both the old and new keys and is now reminding Linux package-manager users to refresh before the cutoff. Anyone who has rerun GitHub’s Linux installation steps since the new keyring was published is already covered. The change affects `gh` installed or updated through apt, yum or dnf; Windows, macOS, Homebrew, Conda, precompiled binaries and source builds are not affected by this repository-key rollover.

Why it matters

Repository signing failures often surface as a broken update path rather than an obvious application failure. CI images, developer workstations and long-lived servers that configured GitHub CLI months ago can continue running their existing binary while silently carrying the old keyring, then fail the next package update after September 5. The fix is small, but the cutoff is immediate and easy to miss because it lives in package-repository configuration rather than the CLI release itself.

The expiration affects repository verification, not the installed CLI

An existing `gh` binary does not stop working when the PGP key expires. The problem appears when apt, yum or dnf tries to verify package metadata or a new package using repository trust material that has not been refreshed.

Rerunning GitHub’s distro setup picks up the new keyring

GitHub’s replacement keyring includes the new signing key. Users who refreshed their Linux installation configuration after April 8 already have it; older installations should repeat the current repository setup steps for their distribution.

Many common installation paths are outside the blast radius

GitHub says the rollover does not affect Windows or macOS installs, source builds, Homebrew, Conda or precompiled binaries. Teams should therefore identify how `gh` is installed before applying a fleet-wide remediation.

What to watch next

  • Any post-expiry package-manager errors from installations that missed the keyring refresh.
  • Whether old container images or infrastructure bootstrap scripts continue installing the expired key.
  • Future GitHub CLI signing-key rotations and whether repository packages automate trust-key rollover more completely.

Still unclear

  • The practical failure message varies by Linux distribution and package manager.
  • Hosts that do not update `gh` immediately after September 5 may not reveal the stale keyring until a later package operation.

Sources

Direct reading behind this dossier.

2 sources

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment
Continue reading
Web Development

Apple puts Intel-only Mac apps on a Rosetta end-of-life path

Rosetta’s transition is now an application compatibility deadline rather than an open-ended safety net. Intel-only Mac apps need an Apple-silicon build before support ends after macOS 27, with only a narrow exception retained for older unmaintained games.