La clé de signature de GitHub CLI expire le 5 septembre, les paquets Linux cesseront de s’installer
Le samedi 5 septembre 2026, la clé PGP qui signe les dépôts APT et RPM de GitHub CLI expire, et toute installation de gh faite avant le 8 avril sans mise à jour de la keyring commencera à échouer. Vérifiez votre keyring locale avant la date butoir et ajoutez la nouvelle clé 7F38BBB59D064DBCB3D84D725612B36462313325.
5 septembre 2026. La clé PGP qui signe les paquets Linux de GitHub CLI (gh) expire, à 12 h 44 UTC. 8 avril 2026. GitHub avait pourtant publié une keyring contenant déjà la clé de remplacement — il suffisait de réinstaller selon les consignes. Septembre 2024. Le même scénario avait cassé les dépôts pendant plusieurs jours, contraint GitHub à prolonger la clé en urgence. Pourquoi c’est grave : toute machine qui a installé gh via APT ou RPM avant le 8 avril 2026 et n’a rien refait depuis verra ses apt update, dnf update ou yum install échouer à partir de samedi — y compris dans les images de CI/CD reconstruites la nuit.
Une rotation annoncée, mais une date butoir têtue
GitHub n’a pas été pris de court cette fois. Depuis le 8 avril 2026, l’issue #13118 du dépôt cli/cli documente la rotation, et les fichiers de keyring publiés contiennent les deux clés : l’ancienne — 2C6106201985B60E6C7AC87323F3D4EA75716059, qui expire le 5 septembre 2026 — et la nouvelle — 7F38BBB59D064DBCB3D84D725612B36462313325. À partir de la première version publiée après cette date, les métadonnées des dépôts APT et RPM ne seront plus signées qu’avec la nouvelle clé.
Le problème est mécanique, pas documentaire. Un système qui ne possède que l’ancienne clé dans sa keyring refusera la signature nouvelle avec une erreur du type EXPKEYSIG ou NO_PUBKEY, et l’installation ou la mise à jour de gh échouera. Les messages d’échec sont nombreux selon le gestionnaire, mais tous pointent la même cause : la clé locale est devenue obsolète.
Le précédent de septembre 2024 explique la prudence. À l’époque, la clé avait expiré sans rotation préparée, et GitHub avait dû prolonger la clé existante en urgence après une panne des dépôts. Cette fois, la rotation est proactive — mais elle exige que chaque utilisateur concerné fasse le pas manquant.
Qui est touché, qui ne l’est pas
Le périmètre est précis. Vous êtes concerné si vous avez installé gh via les dépôts officiels APT ou RPM avant le 8 avril 2026 et n’avez pas relancé les étapes d’installation depuis. C’est le cas typique d’une image de conteneur figée, d’un golden image de VM, ou d’une machine provisionnée il y a des mois par un script Ansible ou Terraform jamais ré-exécuté.
Vous n’êtes pas concerné si vous utilisez Windows ou macOS, si vous compilez depuis les sources, ou si gh est installé via Homebrew, Conda, un gestionnaire communautaire, un .deb direct ou un binaire autonome de GitHub Releases. Ces canaux ne passent pas par la clé PGP des dépôts.
La règle simple pour ceux qui ne se souviennent pas de la date d’installation : vérifier le contenu de la keyring locale. Si elle contient deux clés publiques, vous êtes déjà couvert.
Vérifier sa keyring locale
Le contrôle prend une commande. Sur Debian ou Ubuntu, la keyring vit normalement dans /etc/apt/keyrings/ :
gpg --show-keys /etc/apt/keyrings/githubcli-archive-keyring.gpgSi le fichier n’y est pas, essayez l’ancien emplacement /usr/share/keyrings/githubcli-archive-keyring.gpg, ou lisez la source du dépôt pour retrouver le chemin référencé par l’option signed-by= :
cat /etc/apt/sources.list.d/github-cli.listSi la sortie de gpg --show-keys affiche deux blocs pub — un avec l’empreinte 2C6106201985B60E6C7AC87323F3D4EA75716059 et un avec 7F38BBB59D064DBCB3D84D725612B36462313325 — votre keyring est à jour et il n’y a rien à faire. Une seule empreinte, l’ancienne, et vous devez corriger avant samedi.
Corriger sur APT et RPM
La correction consiste à réimporter la keyring qui contient les deux clés, puis à rafraîchir le paquet. Sur Debian/Ubuntu :
sudo mkdir -p -m 755 /etc/apt/keyrings
wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg \
| sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null
sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \
| sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null
sudo apt update
sudo apt install ghSur Fedora, RHEL, CentOS ou Amazon Linux 2, on ré-enregistre le dépôt RPM puis on met à jour :
# dnf (Fedora 41+, RHEL, CentOS)
sudo dnf config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo dnf update gh
# yum (Amazon Linux 2)
sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://cli.github.com/packages/rpm/gh-cli.repo
sudo yum update ghSi une erreur de vérification de clé persiste après ces étapes, il faut retirer l’ancienne clé du trousseau RPM avant de réinstaller. La commande rpm -qa gpg-pubkey liste les clés ; l’ancienne porte généralement le nom gpg-pubkey-75716059-63172e8a. On la supprime avec rpm -e gpg-pubkey-75716059-63172e8a, puis dnf remove gh suivi de dnf install gh.
Reconnaître l’échec dans les logs
Le symptôme est reconnaissable entre mille. Sur APT, l’erreur cite explicitement la clé expirée ou absente :
W: Failed to fetch https://cli.github.com/packages/dists/stable/InRelease
The following signatures were invalid: EXPKEYSIG 23F3D4EA75716059 GitHub CLI
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 5612B36462313325Sur RPM, le message varie — Signature verification failed, ou un repomd.xml signé « with an unknown key » — mais le diagnostic est le même : la keyring ne contient pas la nouvelle clé. Dans un pipeline, l’échec se manifeste rarement par un beau message : c’est un apt-get install gh qui sort en code non nul au milieu d’un Dockerfile, sans que personne ne regarde la cause. D’où l’intérêt de tester la commande de vérification à l’avance plutôt que de découvrir l’expiration en production.
Pourquoi c’est plus qu’un désagrément
Une clé de signature qui expire n’est pas une vulnérabilité au sens classique. Mais elle produit le même symptôme qu’une attaque de chaîne d’approvisionnement : le gestionnaire de paquets refuse de valider ce qu’il reçoit. C’est exactement le comportement que l’on veut préserver — la vérification de signature doit échouer quand elle ne peut plus prouver l’origine du paquet. La leçon n’est donc pas « désactivez la vérification », mais « gérez les rotations comme un actif d’infrastructure ».
L’impact réel se concentre dans les pipelines. Une image de CI/CD qui installe gh via apt et se reconstruit chaque nuit échouera silencieusement à partir de samedi si sa recette n’a pas été touchée depuis avril. Le correctif n’est pas un patch applicatif, mais une mise à jour de la recette d’image — à propager dans les Dockerfiles, les playbooks Ansible et les modules Terraform qui figent l’état des machines.
La bonne pratique de fond est de ne jamais laisser une keyring ou un dépôt en jachère. Les rotations de clés de signature, chez GitHub, Docker, Microsoft ou Google, suivent toutes le même cycle : annonce, publication d’une clé de remplacement, expiration. Une équipe qui provisionne par du code devrait traiter la date d’expiration d’une clé comme une échéance de maintenance à planifier, au même titre qu’un certificat TLS.
Prévenir la prochaine expiration
Le correctif ponctuel ne suffit pas : la clé de remplacement a elle-même une date de fin, et d’autres dépôts suivront le même cycle. Deux réflexes réduisent la charge. D’abord, intégrer la vérification de keyring à l’image de base et à ses tests, pour qu’une recette cassée échoue en CI et non en production. Ensuite, traiter les dépôts tiers comme des dépendances à renouveler : un inventaire des clés et certificats avec leurs dates d’expiration, relu chaque mois, coûte moins cher qu’un réveil en panne.
Verdict
Si vous installez gh via APT ou RPM, lancez aujourd’hui la vérification en une commande (gpg --show-keys sur la keyring) et réimportez la keyring à deux clés avant le 5 septembre. C’est cinq minutes par machine, contre une panne de pipeline lundi matin.
Si vous maintenez des images ou des playbooks, mettez à jour la recette qui installe gh et forcez une reconstruction de vos images de base. Ne « corrigez » pas en désactivant la vérification de signature : vous échangeriez une panne annoncée contre un trou de chaîne d’approvisionnement permanent.
Dans tous les cas, traitez cette échéance comme un rappel : les clés de signature, comme les certificats, ont une date de fin. Un inventaire des expirations à venir — clés de dépôts, certificats internes, secrets de rotation — vaut mieux qu’un réveil en panne un samedi.