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 gpg2
fallar cuando gpg
funciona 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í strace
y 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-agent
vuelve 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
fuente
gpg-agent
, y el programa de pinentry necesitaba ser configuradopinentry-gtk-2
. Antes de configurarlopinentry-gnome3
, que existía en mi sistema, pero no funcionó. Tuve que instalar manualmentepinentry-gtk-2
.Respuestas:
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 -k
ygpg -K
era 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 ambosgpg -k
ygpg -K
ahora 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 unaconnect()
llamada justo después de leer el pubring.Si GnuPG no migró automáticamente las claves, simplemente importe toda la grabación directamente:
Para verificar el contenido del agente manualmente:
Estos son "keygrips" - compárelos con la grabación de GnuPG:
fuente
gpg --gen-key
que quería usargopass
. Desafortunadamente, losgopass
usosgpg2
...gpg2 --import
funcionaron de maravilla ¡Gracias!gpg2 --import ~/.gnupg/pubring.gpg
arreglé.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".fuente