7

Recently, my pass password manager has started taking upwards of 45 seconds to bring up the gpg-agent password prompt for my master password, which is super annoying when I'm trying to log into a website and have to sit there staring at the password prompt for a minute.

I started doing some tests and found there seems to be something wrong with the gpg2 agent. When I run gpg1, without any agent configured, it's very fast (and this includes the time to type my password):

$ time gpg -vvv -d BitBucket.gpg
real    0m2.940s
user    0m0.024s
sys     0m0.004s

But when I run gpg2 against the same file (agent required to use gpg2), it's crazy slow:

$ time gpg2 -vvv -d BitBucket.gpg
real    0m53.421s
user    0m0.000s
sys     0m0.004s

Yet, now that the agent has my password cached, it's fast again:

$ time gpg2 -vvv -d BitBucket.gpg
real    0m0.126s
user    0m0.004s
sys     0m0.000s

It's not the decryption that's slow -- once the password prompt finally comes up, it decrypts in a more or less normal amount of time. It's just that the agent takes forever to load and display the password prompt.

The verbose logs do not yield anything useful. The output looks like this (irrelevant and/or sensitive information replaced with <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

I tried killing and manually reloading gpg-agent with the --log-file option as described in the man page, hoping to get an explanation of what was taking so long, but the only line that was ever printed after I did several decryption operations was:

2019-07-24 17:49:13 gpg-agent[19648] gpg-agent (GnuPG) 2.1.11 started

Which obviously isn't very helpful!

I tried changing the pinentry-program in my ~/.gnupg/gpg-agent.conf, but different GUIs behaved similarly.

I found this thread, but that seems to be about encrypting (that would plausibly block due to a lack of randomness, but true randomness seems an unlikely need for starting the gpg-agent).

I also found a thread about --check-trustdb being slow and this sometimes executing on every command, but I ran --check-trustdb myself and it finished without a perceptible delay:

$ time gpg2 -vvv --check-trustdb
real    0m0.009s
user    0m0.008s
sys     0m0.000s

Any ideas what I could try next to get to the bottom of this?

Soren Bjornstad
  • 423

3 Answers3

4

The issue is in fact related to pinentry, but only indirectly. It won't happen with those pinentry-* implementations which don't try querying a keyring daemon.

The deamon in use is likely to be gnome-keyring-daemon which is what causes the hang (there are a few other implementations of keyrings, by the way). From a GPG bug report:

The delay is caused by the pinentry querying the GNOME keyring. Add no-allow-external-cache to your gpg-agent.conf, or fix your GNOME installation, or report the problem to the GNOME people.

Some other possible solutions:

  • killall gnome-keyring-daemon (will be started on the next use automatically and might not hang anymore, no need for a reboot)
  • uninstalling gnome-keyring package if you don't use it
xaizek
  • 1,261
3

On my Debian system, the long delay before GPG presents a passphrase prompt was caused by the pinentry program. It was set to pinentry-gnome3 by default, and changing it to pinentry-curses seems to have fixed the problem.

I notice in your question that you say different GUIs for pinentry-program behaved similarly. Also that the problem disappeared after a reboot, so it seems likely that you were facing a different issue. I've encountered this long delay on a few systems over the years, and in some cases rebooting has not helped, so I'll record this answer in case anyone else finds it useful.

To fix it, I ran this command, and selected pinentry-curses:

sudo update-alternatives --config pinentry

For non-Debian systems, you can check which one is symlinked to /usr/bin/pinentry:

ls -l /usr/bin/pinentry

Updating it might look something like this:

sudo rm /usr/bin/pinentry
sudo ln -s /usr/bin/pinentry-curses /usr/bin/pinentry

Exercise some caution, especially if /usr/bin/pinentry is not a symlink. Your distribution may have another way to do this.

After updating it to use pinentry-curses (or pinentry-tty), the long delay disappears.

Jude Hungerford
  • 31
0

Stumped, I did the Windows-user thing and rebooted my PC (even though I'm running Linux on here), and surprisingly the problem disappeared. I guess there must have been some kind of contention issue with another running process.

I'll come back and update if this happens again and I'm able to identify what the specific culprit was. The entries listed by lsof for the gpg-agent don't seem to suggest any likely issues, and I double-checked to be sure there weren't any other running agents or GPG processes.

Soren Bjornstad
  • 423