gpg2: pas de clé secrète

J'utilise enigmail depuis plus d'un an sans problème, et aujourd'hui cela ne fonctionne pas.

J'ai trouvé le fait intéressant suivant:

gpg --decrypt something.gpg # this works
gpg2 --decrypt something.gpg # this fails

Donc, quelque chose est cassé avec la version 2 de gpg sur ma machine.

Cela m'a amené à constater que:

gpg --list-secret-keys # reads from ~/.gnupg/secring.gpg
gpg2 --list-secret-keys # reads from ~/.gnupg/pubring.gpg (pubring?!) 

Cela semble être la racine du problème ... bien sûr, gpg2ne peut pas trouver la clé secrète car elle cherche dans le mauvais fichier.

Comment mon gpg2échec pourrait -ilgpg œuvres fonctionnent bien? Je ne vois aucune option pour spécifier d'où les clés secrètes sont lues.

Quelqu'un a des idées?

Réponse à @grawity :

Merci, j'apprécie votre aide. J'ai courustrace et je vois de quoi tu parles.

Cependant, même après gpg2 --import ...je ne vois aucune différence de comportement. Je ne peux le faire fonctionner que si je redémarre (sans démarrer gpg-agent), exécute gpg2 --import ..., puis exécute gpg2 --decrypt .... Après cette séquence, thunderbird + enigmail se comporte également bien. Cependant, après environ 15 minutes (je suppose que le mot de passe que j'ai entré pour déchiffrer a expiré), puisgpg-agent revient à son ancien comportement. Cette séquence est reproductible.

Voici donc une sortie si elle permet de clarifier quoi que ce soit:

sortie de gpg2 -K:

/home/<username>/.gnupg/pubring.gpg
---------------------------------
sec   rsa4096/AAAAAAAA <date> [SC]
uid         [ultimate] <description of me>
ssb   rsa4096/BBBBBBBB <date> [E]

sortie de gpg-connect-agent

> keyinfo --list
S KEYINFO <keygrip associated with AAAAAAAA> D - - - P - - -
S KEYINFO <keygrip associated with BBBBBBBB> D - - - P - - -
OK

sortie de gpg2 -v -r <my email> -e testfile

gpg: using PGP trust model
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: This key belongs to us
gpg: reading from 'testfile'
gpg: writing to 'testfile.gpg'
gpg: RSA/AES256 encrypted for: "BBBBBBBB <description of me>"

sortie de gpg2 -v -d testfile.gpg

gpg: public key is BBBBBBBB
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: using subkey BBBBBBBB instead of primary key AAAAAAAA
gpg: encrypted with 4096-bit RSA key, ID BBBBBBBB, created <date>
      "<description of me>"
gpg: public key decryption failed: Operation cancelled
gpg: decryption failed: No secret key

… Bien sûr, gpg2 ne trouve pas la clé secrète car il cherche dans le mauvais fichier.

Ce n'est pas le seul fichier qu'il regarde.

Dans GnuPG 1.x (et 2.0), le "secret" avait également une copie en double des données publiques de votre keyblock, il était donc entièrement autonome (et la seule différence entre gpg -ket gpg -Kétait le fichier qu'il avait lu) , mais en même temps plus difficile à maintenir pour le programme.

Dans GnuPG 2.1, les clés secrètes sont désormais stockées indépendamment - elles sont gérées par gpg-agent , qui les conserve ~/.gnupg/private-keys-v1.d/. Donc , à la fois gpg -ket gpg -Ksont maintenant de lire les informations OpenPGP du pubring, mais celui - ci demande en outre gpg-agent dont les certificats ont les clés secrètes associées. Si vous utilisez strace , vous devriez remarquer un connect()appel juste après avoir lu le pubring.

Si GnuPG n'a pas migré automatiquement les clés, il suffit d'importer le tout directement directement:

gpg2 --import ~/.gnupg/secring.gpg

Pour vérifier manuellement le contenu de l'agent:

$ gpg-connect-agent 
> keyinfo --list
S KEYINFO 926145FFCA32B3E6E079A0CF73EA77C40733A349 D - - - P - - -
S KEYINFO BACFB81EAFC864F4AB2926E8B1F55AD579F78D1A D - - - P - - -
S KEYINFO FF3D1DD51B9C79E148CCCEA5F7F3E25EC96048B7 D - - - P - - -
S KEYINFO 4D29EF1460F164CDB11D0FC0247214660ACDD60F D - - - P - - -
S KEYINFO 06B13685B9AA429B9CABCE480930D74B991C8DF0 D - - - P - - -
S KEYINFO B28DB8D045654E8A6A40466A07FCD9E432935E29 D - - - P - - -
D'accord
> / bye 
$

Ce sont des "clés" - comparez-les avec le secret de GnuPG:

$ gpg --list-secret-keys --with-keygrip
/home/fred/.gnupg/pubring.kbx
--------------------------------
sec ed25519 2018-08-18 [SC]
      2357E133AD5D24F6CB2C1B0CEF4F7ED27E252632
      Keygrip = 4D29EF1460F164CDB11D0FC0247214660ACDD60F 
uid [ultime] Fred Foobar <fred@example.com>

Finalement, j'ai décidé que le problème était que j'utilisais Debian Unstable et qu'il y avait un décalage de version introduit par un apt-get dist-upgrade. Je suppose que c'est pourquoi ils l'appellent "instable".