gpg2 rodando excessivamente lento, somente quando o agente não tem senha armazenada em cache

gpg2 rodando excessivamente lento, somente quando o agente não tem senha armazenada em cache

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-agentcom a --log-fileopçã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-programmeu ~/.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-trustdbser lento e às vezes executar todos os comandos, mas eu --check-trustdbmesmo 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-daemono 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-cacheao 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-keyringo 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 pinentryprograma. Ele foi definido pinentry-gnome3como padrão e alterá-lo pinentry-cursesparece ter resolvido o problema.

Percebo na sua pergunta que você diz que GUIs diferentes pinentry-programse 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/pinentrynã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 lsofpara 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.

informação relacionada