Sauver un GnuPG corrompu
Note de service : still alive, blog mis à jour et on va essayer d’y poster un peu plus en 2020…
Ces derniers jours, j’ai remarqué qu’un processus GnuPG prenait inhabituellement beaucoup de temps et CPU.
Une commande gpg --list-keys semblait tourner en boucle pendant de longues minutes.
Avec un peu de recherche, je comprends que j’avais importé une clef victime de l’attaque de spam de signature GnuPG annoncée il y a quelques mois.
$ ls -lh ~/.gnupg/pubring.gpg ... 33M ...
Une (ou plusieurs) clef a été signée des centaines de milliers de fois, rendant le système inutilisable. Une attaque simple mais pourtant assez difficile à régler pour des raisons peu rassurantes:
Why Hasn’t It Been Fixed?
There are powerful technical and social factors inhibiting further keyserver development.
The software is Byzantine. The standard keyserver software is called SKS, for « Synchronizing Key Server ». A bright fellow named Yaron Minsky devised a brilliant algorithm that could do reconciliations very quickly. It became the keystone of his Ph.D thesis, and he wrote SKS originally as a proof of concept of his idea. It’s written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that’s deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that’s literally someone’s Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.
[…]
On utilise donc un proof-of-concept comme serveur de clef GPG et personne ne sait exactement comment il fonctionne. Joie.
Solution
La solution la plus simple serait évidemment de supprimer l’ensemble du répertoire ~/.gnupg et de recommencer. Si, pour de bonnes raisons, cette solution ne vous plaît pas, il nous faudra identifier la ou les clefs problématiques et les supprimer.
Attention, toutes les commandes ci-dessous sont très lentes (une quinzaine de minute chez moi) ! Pensez à prendre un café…
D’abord, identifier la clef problématique :
$ gpg --export | gpg --list-packets | awk -F= -v oldoff=-1 -v keyid=unset '
/^# off=/{ off = $2 + 0 }
/^:public key/{ if (oldoff>-1) { print (off - oldoff) " " keyid }; oldoff = off; keyid = "unset"; }
/keyid:/ {if (keyid == "unset") { keyid = $1; } }
END { print (off - oldoff) " " keyid ; };' | sort -n
...
18420 keyid: D9C4D26D0E604491
19724 keyid: 4A95E75A1354AAF0
15874931 keyid: DB1187B9DD5F693B
15923848 keyid: 4E2C6E8793298290
La (grande) commande bash ci-dessous vous listera vos clefs avec la taille de celles-ci. Les deux dernières avec une taille à 8 chiffres sont les clefs problématiques.
Si l’on veut les garder (au cas où), vous pouvez les exporter en plaintext (ce qui donne un fichier de 21MB pour la clef ci-dessous)
$ gpg -a --export 'DB1187B9DD5F693B' > badkey.asc
Mais, il y a de bonnes chances que vous désiriez plutôt les supprimer.
$ gpg --delete-key 'DB1187B9DD5F693B' gpg (GnuPG) 2.2.17; Copyright (C) 2019 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub rsa4096/DB1187B9DD5F693B 2015-01-17 Patrick BrunschwigDelete this key from the keyring? (y/N) y gpg: removing stale lockfile (created by 598252)
Après la suppression des clefs problématiques, tout devrait rentrer dans l’ordre !
Source des commandes : Mitigating Poisoned PGP Certificates (CVE-2019-13050)
