Recentemente, meupassarO gerenciador de senhas começou a levar mais de 45 segundos para exibir o prompt de senha do gpg-agent para minha senha mestra, o que é muito irritante quando estou tentando fazer login em um site e tenho que ficar parado olhando para o prompt de senha por um minuto .
Comecei a fazer alguns testes e descobri que parece haver algo errado com o agente gpg2. Quando executo o gpg1, sem nenhum agente configurado, é muito rápido (e isso inclui o tempo para digitar minha senha):
$ time gpg -vvv -d BitBucket.gpg
real 0m2.940s
user 0m0.024s
sys 0m0.004s
Mas quando executo o gpg2 no mesmo arquivo (agente necessário para usar o gpg2), ele fica muito lento:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m53.421s
user 0m0.000s
sys 0m0.004s
No entanto, agora que o agente armazenou minha senha em cache, é rápido novamente:
$ time gpg2 -vvv -d BitBucket.gpg
real 0m0.126s
user 0m0.004s
sys 0m0.000s
Não é a descriptografia que é lenta – quando a solicitação da senha finalmente aparece, ela é descriptografada em um período de tempo mais ou menos normal. Acontece que o agente leva uma eternidade para carregar e exibir o prompt de senha.
Os logs detalhados não produzem nada de útil. A saída é semelhante a esta (informações irrelevantes e/ou confidenciais substituídas 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
Tentei matar e recarregar manualmente gpg-agent
com a --log-file
opção descrita na página de manual, na esperança de obter uma explicação do que estava demorando tanto, mas a única linha que foi impressa depois de fazer várias operações de descriptografia foi:
2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started
O que obviamente não é muito útil!
Tentei alterar o pinentry-program
meu ~/.gnupg/gpg-agent.conf
, mas diferentes GUIs se comportaram de maneira semelhante.
eu encontreieste tópico, mas isso parece ser sobre criptografia (isso seria plausivelmente bloqueado devido à falta de aleatoriedade, mas a verdadeira aleatoriedade parece uma necessidade improvável para iniciar o agente gpg).
Eu também encontrei umfiosobre --check-trustdb
ser lento e às vezes executar todos os comandos, mas eu --check-trustdb
mesmo corri e terminou sem um atraso perceptível:
$ time gpg2 -vvv --check-trustdb
real 0m0.009s
user 0m0.008s
sys 0m0.000s
Alguma idéia do que eu poderia tentar a seguir para chegar ao fundo disso?
Responder1
A questão está de fato relacionada com pinentry
, mas apenas indiretamente. Isso não acontecerá com aquelas pinentry-*
implementações que não tentam consultar um daemon de chaveiro.
É provável que o deamon em uso seja gnome-keyring-daemon
o que causa o travamento (a propósito, existem algumas outras implementações de chaveiros). A partir de umRelatório de bug do GPG:
O atraso é causado pela consulta do pinentry ao chaveiro do GNOME. Adicione
no-allow-external-cache
ao seu gpg-agent.conf, ou corrija a instalação do GNOME, ou relate o problema ao pessoal do GNOME.
Algumas outras soluções possíveis:
killall gnome-keyring-daemon
(será iniciado automaticamente no próximo uso e pode não travar mais, não há necessidade de reinicialização)- desinstalando
gnome-keyring
o pacote se você não o usar
Responder2
No meu sistema Debian, o longo atraso antes que o GPG apresentasse um prompt de senha foi causado pelo pinentry
programa. Ele foi definido pinentry-gnome3
como padrão e alterá-lo pinentry-curses
parece ter resolvido o problema.
Percebo na sua pergunta que você diz que GUIs diferentes pinentry-program
se comportam de maneira semelhante. Além disso, o problema desapareceu após a reinicialização, então parece provável que você estivesse enfrentando um problema diferente. Encontrei esse longo atraso em alguns sistemas ao longo dos anos e, em alguns casos, a reinicialização não ajudou, então registrarei esta resposta caso alguém a considere útil.
Para consertar, executei este comando e selecionei pinentry-curses
:
sudo update-alternatives --config pinentry
Para sistemas não-Debian, você pode verificar qual deles está vinculado simbolicamente /usr/bin/pinentry
:
ls -l /usr/bin/pinentry
Atualizá-lo pode ser algo assim:
sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry
Tenha cuidado, especialmente se /usr/bin/pinentry
não for um link simbólico. Sua distribuição pode ter outra maneira de fazer isso.
Depois de atualizá-lo para usar pinentry-curses
(ou pinentry-tty
), o longo atraso desaparece.
Responder3
Perplexo, fiz a coisa de usuário do Windows e reiniciei meu PC (embora esteja executando o Linux aqui) e, surpreendentemente, o problema desapareceu. Acho que deve ter havido algum tipo de problema de contenção com outro processo em execução.
Voltarei e atualizarei se isso acontecer novamente e conseguir identificar qual foi o culpado específico. As entradas listadas por lsof
para o agente gpg não parecem sugerir quaisquer problemas prováveis, e verifiquei novamente para ter certeza de que não havia outros agentes ou processos GPG em execução.