Recientemente, miaprobarEl administrador de contraseñas ha comenzado a tardar más de 45 segundos en mostrar la solicitud de contraseña de gpg-agent para mi contraseña maestra, lo cual es muy molesto cuando intento iniciar sesión en un sitio web y tengo que quedarme sentado mirando la solicitud de contraseña durante un minuto. .
Comencé a hacer algunas pruebas y descubrí que parece haber algún problema con el agente gpg2. Cuando ejecuto gpg1, sin ningún agente configurado, es muy rápido (y esto incluye el tiempo para escribir mi contraseña):
$ time gpg -vvv -d BitBucket.gpg
real 0m2.940s
user 0m0.024s
sys 0m0.004s
Pero cuando ejecuto gpg2 en el mismo archivo (se requiere agente para usar gpg2), es increíblemente lento:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m53.421s
user 0m0.000s
sys 0m0.004s
Sin embargo, ahora que el agente tiene mi contraseña en caché, vuelve a ser rápido:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m0.126s
user 0m0.004s
sys 0m0.000s
No es el descifrado lo que es lento: una vez que finalmente aparece la solicitud de contraseña, se descifra en un período de tiempo más o menos normal. Es sólo que el agente tarda una eternidad en cargar y mostrar la solicitud de contraseña.
Los registros detallados no arrojan nada útil. El resultado se ve así (información irrelevante y/o confidencial reemplazada por <angle-bracketed text>:
$ gpg2 -vvv -d BitBucket.gpg
gpg: using character set 'utf-8'
<key parameters>
:pubkey enc packet: version 3, algo 1, keyid <X>
data: [2048 bits]
gpg: public key is <Y>
gpg: using subkey <Y> instead of primary key <Z>
[...here it locks up for 45-ish seconds and then pops up the agent prompt]
gpg: public key encrypted data: good DEK
<key parameters>
:encrypted data packet:
length: 200
mdc_method: 2
gpg: using subkey <Y> instead of primary key <Z>
gpg: encrypted with 2048-bit RSA key, ID <Y>, created 2012-03-07
<ME>
gpg: AES256 encrypted data
<key parameters>
:literal data packet:
mode b (62), created 1525637737, name="",
raw data: 151 bytes
gpg: original file name=''
<the content of the password file>
gpg: decryption okay
Intenté eliminar y recargar manualmente gpg-agentcon la --log-fileopción como se describe en la página de manual, con la esperanza de obtener una explicación de por qué estaba tardando tanto, pero la única línea que se imprimió después de realizar varias operaciones de descifrado fue:
2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started
¡Lo cual obviamente no es muy útil!
Intenté cambiar pinentry-programen mi ~/.gnupg/gpg-agent.conf, pero diferentes GUI se comportaron de manera similar.
encontréeste hilo, pero parece que se trata de cifrado (eso posiblemente se bloquearía debido a la falta de aleatoriedad, pero la verdadera aleatoriedad parece una necesidad poco probable para iniciar el agente gpg).
También encontré unhilosobre --check-trustdbser lento y esto a veces se ejecuta en cada comando, pero lo ejecuté --check-trustdbyo mismo y terminó sin un retraso perceptible:
$ time gpg2 -vvv --check-trustdb
real 0m0.009s
user 0m0.008s
sys 0m0.000s
¿Alguna idea de qué podría intentar a continuación para llegar al fondo de esto?
Respuesta1
De hecho, el problema está relacionado con pinentry, pero sólo indirectamente. No sucederá con aquellas pinentry-*implementaciones que no intentan consultar un demonio de llavero.
Es probable que el demonio en uso sea gnome-keyring-daemonel que causa el bloqueo (por cierto, hay algunas otras implementaciones de llaveros). A partir de unaInforme de error GPG:
El retraso se debe a que pinentry consulta el llavero de GNOME. Agréguelo
no-allow-external-cachea su gpg-agent.conf, arregle su instalación de GNOME o informe el problema a la gente de GNOME.
Algunas otras posibles soluciones:
killall gnome-keyring-daemon(se iniciará automáticamente en el próximo uso y es posible que ya no se cuelgue, no es necesario reiniciar)- desinstalar
gnome-keyringel paquete si no lo usas
Respuesta2
En mi sistema Debian, el largo retraso antes de que GPG presente una solicitud de contraseña fue causado por el pinentryprograma. Estaba configurado pinentry-gnome3de forma predeterminada y cambiarlo pinentry-cursesparece haber solucionado el problema.
Noto en tu pregunta que dices que diferentes GUI pinentry-programse comportan de manera similar. Además, el problema desapareció después de reiniciar, por lo que parece probable que estés enfrentando un problema diferente. Me he encontrado con este largo retraso en algunos sistemas a lo largo de los años y, en algunos casos, reiniciar no ha ayudado, así que registraré esta respuesta en caso de que alguien más la encuentre útil.
Para solucionarlo, ejecuté este comando y seleccioné pinentry-curses:
sudo update-alternatives --config pinentry
Para sistemas que no son Debian, puede verificar cuál está vinculado simbólicamente /usr/bin/pinentry:
ls -l /usr/bin/pinentry
Actualizarlo podría verse así:
sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry
Tenga cierta precaución, especialmente si /usr/bin/pinentryno es un enlace simbólico. Es posible que su distribución tenga otra forma de hacer esto.
Después de actualizarlo para usarlo pinentry-curses(o pinentry-tty), la larga demora desaparece.
Respuesta3
Perplejo, hice lo de usuario de Windows y reinicié mi PC (aunque estoy ejecutando Linux aquí) y, sorprendentemente, el problema desapareció. Supongo que debe haber habido algún tipo de problema de disputa con otro proceso en ejecución.
Volveré y actualizaré si esto vuelve a suceder y puedo identificar cuál fue el culpable específico. Las entradas enumeradas por lsofpara gpg-agent no parecen sugerir ningún problema probable, y verifiqué dos veces para asegurarme de que no hubiera otros agentes en ejecución o procesos GPG.