gpg2: nessuna chiave segreta

Uso enigmail da oltre un anno senza problemi e oggi non funziona.

Ho trovato il seguente fatto interessante:

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

Quindi qualcosa è rotto con la versione 2 di gpg sulla mia macchina.

Questo mi ha portato a vedere che:

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

Questa sembra essere la radice del problema ... ovviamente gpg2non riesco a trovare la chiave segreta perché sta cercando nel file sbagliato.

Come posso gpg2fallire quando gpgfunziona bene? Non vedo alcuna opzione per specificare da dove vengono lette le chiavi segrete.

Qualcuno ha qualche idea?

Risposta a @grawity :

Grazie, apprezzo il tuo aiuto. Ho corso stracee vedo di cosa stai parlando.

Tuttavia, anche dopo gpg2 --import ...non vedo alcuna differenza nel comportamento. Posso farlo funzionare solo se riavvio (senza avviare gpg-agent), eseguo gpg2 --import ..., quindi eseguo gpg2 --decrypt .... Dopo quella sequenza, anche thunderbird + enigmail si comporta bene. Tuttavia, dopo circa 15 minuti (la mia ipotesi è la password che ho inserito per decrittografare è scaduta), quindi gpg-agentè tornato al suo vecchio comportamento. Questa sequenza è ripetibile.

Quindi ecco un output se aiuta a chiarire qualcosa:

uscita di gpg2 -K:

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

uscita di gpg-connect-agent

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

uscita di 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>"

uscita di 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

... ovviamente gpg2 non riesce a trovare la chiave segreta perché sta cercando nel file sbagliato.

Questo non è l' unico file che sta guardando.

In GnuPG 1.x (e 2.0), la "secessione" aveva anche una copia duplicata dei dati pubblici del tuo blocco tasti, quindi era completamente autonoma (e l'unica differenza tra gpg -ke gpg -Kera quale file avrebbe letto) , ma allo stesso tempo più difficile da mantenere per il programma.

In GnuPG 2.1, le chiavi segrete sono ora memorizzate in modo indipendente - sono gestite da gpg-agent , che le mantiene dentro ~/.gnupg/private-keys-v1.d/. Quindi entrambi gpg -ke gpg -Kora devono leggere le informazioni di OpenPGP dal pubring, ma quest'ultimo chiede inoltre a gpg-agent quali certificati hanno chiavi segrete associate. Se stai usando strace , dovresti notare una connect()chiamata subito dopo aver letto il pubring.

Se GnuPG non ha migrato automaticamente le chiavi, importa semplicemente l'intera secessione direttamente:

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

Per controllare manualmente il contenuto dell'agente:

$ 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 - - -
ok
> / ciao 
$

Questi sono "tasti": confrontali con i secondi di GnuPG:

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

Alla fine, ho deciso che il problema era che stavo usando Debian Unstable e c'era una discrepanza di versione introdotta da un apt-get dist-upgrade. Suppongo che sia per questo che lo chiamano "instabile".