gpg2: sin clave secreta

He estado usando enigmail durante más de un año sin problemas, y hoy no funciona.

Encontré el siguiente hecho interesante:

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

Entonces algo está roto con gpg versión 2 en mi máquina.

Esto me llevó a ver que:

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

Esta parece ser la raíz del problema ... por supuesto gpg2, no puedo encontrar la clave secreta porque está buscando en el archivo incorrecto.

¿Cómo podría gpg2fallar cuando gpgfunciona bien? No veo ninguna opción para especificar de dónde se leen las claves secretas.

¿Alguien tiene ideas?

Respuesta a @grawity :

Gracias, agradezco tu ayuda. Corrí stracey veo de qué estás hablando.

Sin embargo, incluso después de que gpg2 --import ...no veo diferencia en el comportamiento. Solo puedo hacer que funcione si reinicio (sin iniciar gpg-agent), ejecuto gpg2 --import ...y luego ejecuto gpg2 --decrypt .... Después de esa secuencia, thunderbird + enigmail también se comporta bien. Sin embargo, después de aproximadamente 15 minutos (supongo que la contraseña que ingresé para descifrar ha expirado), gpg-agentvuelve a su comportamiento anterior. Esta secuencia es repetible.

Así que aquí hay algo de salida si ayuda a aclarar algo:

salida de gpg2 -K:

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

salida de gpg-connect-agent

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

salida 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>"

salida 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

... por supuesto, gpg2 no puede encontrar la clave secreta porque está buscando en el archivo incorrecto.

Ese no es el único archivo que está mirando.

En GnuPG 1.x (y 2.0), el "secring" solía tener una copia duplicada de los datos públicos de su bloque de teclas también, por lo que era completamente autónomo (y la única diferencia entre gpg -ky gpg -Kera qué archivo leería) , pero al mismo tiempo más difícil de mantener para el programa.

En GnuPG 2.1, las claves secretas ahora se almacenan de forma independiente: son mantenidas por gpg-agent , que las mantiene dentro ~/.gnupg/private-keys-v1.d/. Así que ambos gpg -ky gpg -Kahora tienen que leer la información de OpenPGP de la publicación, pero este último además le pregunta a gpg-agent sobre qué certificados tienen claves secretas asociadas. Si está usando strace , debería notar una connect()llamada justo después de leer el pubring.

Si GnuPG no migró automáticamente las claves, simplemente importe toda la grabación directamente:

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

Para verificar el contenido del agente manualmente:

$ 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 - - -
Okay
> / bye 
$

Estos son "keygrips" - compárelos con la grabación de 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>

Finalmente, decidí que el problema era que estaba usando Debian Unstable y que había una versión que no coincidía apt-get dist-upgrade. Supongo que por eso lo llaman "inestable".