TL;DR : lors d'un gpg --refresh-keys
, le message « XXX signatures not checked due to missing keys » ne matérialise pas forcément l'existence d'un problème.
Y'a des jours, je me demande si j'ai vraiment des compétences en informatique.
J'utilise GnuPG (GPG) version 2.1.18 tel qu'il est packagé dans Debian GNU/Linux Stretch.
Depuis plusieurs semaines, quand je fais un gpg --refresh-keys
, j'ai, toujours, pour chaque clé présente dans mon trousseau, un message « XXX signatures not checked due to missing keys » (XXX peut être un chiffre ou un nombre avec des dizaines voire des centaines pour quelques clés). En plus de cela, le nombre de clés « non modifiées » est toujours égal à celui de « Quantité totale traitée ». J'ai des clés de cryptonerds et de gens connus qui se font signer leur clé tous les deux jours, donc c'pas normal me dis-je. En plus, j'ai des clés expirées de gens plutôt sérieux (sous-entendu : ils ont bien dû repousser la date d'expiration de leur clé, quand même).
Ces derniers jours, j'en arrive à la conclusion que mon GnuPG est cassé. En effectuant des recherches sur le web, on trouve des articles qui évoquent des dysfonctionnements de gestionnaires de paquets (apt, pacman, etc.) sans donner de solutions (autre que de détruire le trousseau GPG) et d'autres qui évoquent l'attaque des serveurs de clés OpenPGP de mi-2019 qui consiste à joindre des centaines de milliers de signatures à une clé afin de saturer GnuPG.
J'ai tenté de débrayer HKPS (protocole de récupération des clés, HKP, sécurisé par TLS)… En vain. J'ai tenté d'utiliser d'autres serveurs de clés que le réseau SKS. En vain. J'ai passé des dizaines de minutes à essayer de trouver une clé empoisonnée dans mon trousseau… En vain.
Je décide de sauvegarder mon dossier .gnupg actuel et de restaurer sa plus vieille sauvegarde. Août 2018. On est bien avant l'attaque des serveurs de clés. Parfait.
Et là, un --refresh-keys
récupère bien de nouvelles identités et de nouvelles signatures. Pourtant, le message « XXX signatures not checked due to missing keys » demeure, y compris sur ma propre clé.
Mais, ça y est, mon cerveau s'est allumé : ce message n'est pas vraiment une erreur. Il dit simplement que, dans mon trousseau, aucune clé publique permet de valider telle signature apposée sur telle clé. Exemple : si Toto a signé ma clé, mais que je n'ai pas la clé publique de Toto dans mon trousseau de clés, alors ce message s'affiche quand GPG examine ma clé.
Comment vérifier cette hypothèse ? Lancer un gpg --refresh-keys
et noter le nombre de signatures qui n'ont pas pu être vérifiées sur ma clé. Avec gpg --list-sigs
, récupérer l'identifiant d'une clé qui a signé ma clé et qui affiche « [identité introuvable] ». La récupérer depuis les serveurs de clés avec gpg --search-keys "<identifiant_clé>"
. Pour ma clé, un gpg --refresh-keys
affiche désormais un nombre moins élevé de signatures invérifiées pour ma clé.
Bref, il y avait aucun problème. Le message « XXX signatures not checked due to missing keys » ne matérialise pas forcément l'existence d'un problème. D'ailleurs, le code retour de mes gpg --refresh-keys
a toujours été 0… Pour ma défense, GnuPG envoie toute la sortie d'un refresh-keys
sur stderr qui est normalement réservée pour les erreurs. C'est, en partie, ce qui m'a induit en erreur. Après vérification, les propriétaires des clés expirées présentes dans mon trousseau ont changé de clé OpenPGP. Quand aux clés qui n'ont reçu aucune nouvelle signature, il faut croire que même les gens connus et les cryptonerds vivent parfois plusieurs semaines sans qu'on signe leur clé OpenPGP.
Point positif : je me suis fait un avis sur le serveur de clés keys.openpgp.org, qui protégerait de l'attaque de mi-2019 (forcément, vu la manière de procéder…) évoquée ci-dessus et qui vise la conformité RGPD. Voir : SKS poisoning, keys.openpgp.org / Hagrid and other non-solutions.