Bug 595808 – app-crypt/gnupg-2.1.15: gpg-agent hangs after pinentry

• Product: Gentoo Linux
• Status: RESOLVED UPSTREAM

[Description Jordan Yelloz 2016-10-01 18:51:58 UTC]

I have recently tried to start using GPG again after not using it for a long time. Previously it worked with no problems. Last time I used it successfully was in the 2.0.x series.

Now I'm using gnupg-2.1.15 and I have imported my old keys using the instructions in the ebuild.

gpg works okay until I try to do anything that requires unlocking my key. Once I enter my password with pinentry, the gpg tool will hang, waiting for gpg-agent to finish its response, I guess. The problem is that gpg-agent is hanging in a worse fashion, using 100% CPU indefinitely until I kill it with SIGKILL, after which unlocking my key fails inside the gpg tool which continues to function as a tool which can list which keys I have.

In this use case, I have attached GDB to the misbehaving gpg-agent task and here's a redacted backtrace:

--

futex_abstimed_wait_cancelable
do_futex_wait
__new_sem_wait_slow
__new_sem_wait
leave_npth 
npth_pselect
handle_connections
main

--

I have also tried working on a brand-new, empty ~/.gnupg directory and I experience a similar behavior of gpg-agent when attempting to generate a new keypair.

[Comment 1 Jordan Yelloz 2016-10-05 21:11:27 UTC]

I've spent some more time looking into this and it seems to be a kernel-related problem, most probably configuration. I've tried chroot-ing into my Gentoo system from systemrescuecd on a 4.4.x kernel (I'm running 4.8.0) and this bug was not encountered.

[Comment 2 Kristian Fiskerstrand (RETIRED) 2016-10-06 17:09:43 UTC]

(In reply to Jordan Yelloz from comment #1)
> I've spent some more time looking into this and it seems to be a
> kernel-related problem, most probably configuration. I've tried chroot-ing
> into my Gentoo system from systemrescuecd on a 4.4.x kernel (I'm running
> 4.8.0) and this bug was not encountered.

Sounds curious, could you increase gpg-agent logging verbosity using 
log-file /home/user/gpg-agent.log
debug-level guru

and gpgconf --reload gpg-agent ?

[Comment 3 Kristian Fiskerstrand (RETIRED) 2016-10-06 17:17:05 UTC]

(In reply to Kristian Fiskerstrand from comment #2)
> (In reply to Jordan Yelloz from comment #1)
> > I've spent some more time looking into this and it seems to be a
> > kernel-related problem, most probably configuration. I've tried chroot-ing
> > into my Gentoo system from systemrescuecd on a 4.4.x kernel (I'm running
> > 4.8.0) and this bug was not encountered.
> 
> Sounds curious, could you increase gpg-agent logging verbosity using 
> log-file /home/user/gpg-agent.log
> debug-level guru
> 
> and gpgconf --reload gpg-agent ?

Also, please attach the build log including a full tests FEATURES run along with emerge --info etc etc

[Comment 4 Jordan Yelloz 2016-10-06 18:57:27 UTC]

Created attachment 449358 [details]
emerge --info gnupg npth libassuan libgpg-error libgcrypt pinentry libksba

[Comment 5 Christian Tietz 2016-10-14 15:45:07 UTC]

Created attachment 450206 [details]
build.log with FEATURES="test"

I experience the exact same issue. Therefore I'm attaching the requested information.

[Comment 6 Christian Tietz 2016-10-14 15:49:52 UTC]

Created attachment 450208 [details]
gpg-agent.log

gpg-agent.log with debug-level guru after attempting to create a new key in a fresh ~/.gnupg directory.

[Comment 7 Christian Tietz 2016-10-14 15:50:39 UTC]

Created attachment 450210 [details]
emerge --info gnupg

[Comment 8 Christian Tietz 2016-10-14 16:40:19 UTC]

Created attachment 450214 [details]
4.8.1-gentoo.config

Just chrooted into my system from sysresccd (kernel 4.4.23) and exactly as was the case with OP it worked. Attaching my kernel config as well.

[Comment 9 Alon Bar-Lev (RETIRED) 2016-10-14 18:41:39 UTC]

Hi Christian,
Can you confirm that gpg-agent takes 100% cpu and that stack is similar to what Jordan reported (please also do this for all threads)? Can you please confirm that pinentry process finished? I guess you are using pinentry-gtk, can you please also try to use the ncurses? I see that the agent is at the stage of storing the key, however, I am unsure if it waits for some external event.

Thanks!

[Comment 10 Alon Bar-Lev (RETIRED) 2016-10-14 18:56:54 UTC]

I am using 4.4.8 and it looks fine.

[Comment 11 Alon Bar-Lev (RETIRED) 2016-10-14 18:58:02 UTC]

(In reply to Alon Bar-Lev from comment #10)
> I am using 4.4.8 and it looks fine.

oh... sorry... 4.8 is not working for you.

[Comment 12 Alon Bar-Lev (RETIRED) 2016-10-14 19:30:54 UTC]

(In reply to Alon Bar-Lev from comment #11)
> (In reply to Alon Bar-Lev from comment #10)
> > I am using 4.4.8 and it looks fine.
> 
> oh... sorry... 4.8 is not working for you.

Cannot reproduce with 4.8.1.

[Comment 13 Jordan Yelloz 2016-10-14 20:14:50 UTC]

Sorry for the lack of response, I've been away for a while.

I'm now running Linux 4.8.1 and I've rebuilt gcc-5.4.0 and glibc-2.23-r2 and I'm no longer hitting the same problem anymore. GPG will now build successfully with FEATURES=test (previously it would hang during the test run). However, I see a different problem in that it's unable to find my secret key for my subkey. gpg-2.0.30 works fine with the same .gnupg directory and attempting to import my secring.gpg does not improve the situation.

I am, however, able to build a new gpg home and keypair and work with that new home normally. This was not previously possible since it would fail during the key generation process.

[Comment 14 Kristian Fiskerstrand (RETIRED) 2016-10-15 10:23:12 UTC]

(In reply to Jordan Yelloz from comment #13)
> Sorry for the lack of response, I've been away for a while.
> 
> I'm now running Linux 4.8.1 and I've rebuilt gcc-5.4.0 and glibc-2.23-r2 and
> I'm no longer hitting the same problem anymore. GPG will now build
> successfully with FEATURES=test (previously it would hang during the test
> run).

Thanks, closing this bug as INVALID and ascribing it to a rogue kernel regression in this case.

> However, I see a different problem in that it's unable to find my
> secret key for my subkey. gpg-2.0.30 works fine with the same .gnupg
> directory and attempting to import my secring.gpg does not improve the
> situation.

This is likely best handled in #gnupg or #gentoo-crypto on IRC (FreeNode network). The key store changes between 2.0 and 2.1 so it isn't strange in itself that they can differ, however, an import should have solved it as long as it can write to private-keys-v1.d/<keygrip-of-subkey>.key. One thing that isn't migrated automatically is smartcard stubs, those can be generated using gpg --card-status when the card is attached. As more of a general note, another variant that will not be migrated is V3 keys, as they are unsafe to use.

> 
> I am, however, able to build a new gpg home and keypair and work with that
> new home normally. This was not previously possible since it would fail
> during the key generation process.

Good

[Comment 15 Christian Tietz 2016-10-16 05:42:04 UTC]

Just for the record: Following Jordan's procedure didn't bring me any joy. Running a mostly stable amd64 system I ended up downgrading to gentoo-sources-4.4.21. As was the case with chroot from sysresccd that worked instantly. So either there is some regression in newer kernels or my config for Linux 4.8.1 was messed up. Obviously not an issue originating from GnuPG. Apologies for the noise.

[Comment 16 Harri Nieminen (Moiman) 2017-01-15 18:17:39 UTC]

with FEATURES=test gnupg still hangs.

[Comment 17 Kristian Fiskerstrand (RETIRED) 2017-01-15 18:26:45 UTC]

(In reply to moikkis from comment #16)
> with FEATURES=test gnupg still hangs.

Please open a new bug with sufficient information to debug

[Comment 18 Harri Nieminen (Moiman) 2017-01-15 19:06:36 UTC]

(In reply to Kristian Fiskerstrand from comment #17)
> (In reply to moikkis from comment #16)
> > with FEATURES=test gnupg still hangs.
> 
> Please open a new bug with sufficient information to debug

https://bugs.gentoo.org/show_bug.cgi?id=605806

[Comment 19 Petre Rodan 2017-07-12 13:23:59 UTC]

(In reply to Christian Tietz from comment #15)
> Just for the record: Following Jordan's procedure didn't bring me any joy.
> Running a mostly stable amd64 system I ended up downgrading to
> gentoo-sources-4.4.21. As was the case with chroot from sysresccd that
> worked instantly. So either there is some regression in newer kernels or my
> config for Linux 4.8.1 was messed up. Obviously not an issue originating
> from GnuPG. Apologies for the noise.

I ended up having this problem myself for the last few months. today I decided to look into it.

long story short a tickless kernel will make the agent wrongly detect the speed of encryption and thus it keeps incrementing the number of iterations sent to gcrypt lib function.

an upstream bug has been filed here: https://dev.gnupg.org/T3276

[Comment 20 Kristian Fiskerstrand (RETIRED) 2017-07-12 14:34:25 UTC]

(In reply to Petre Rodan from comment #19)
> (In reply to Christian Tietz from comment #15)
> > Just for the record: Following Jordan's procedure didn't bring me any joy.
> > Running a mostly stable amd64 system I ended up downgrading to
> > gentoo-sources-4.4.21. As was the case with chroot from sysresccd that
> > worked instantly. So either there is some regression in newer kernels or my
> > config for Linux 4.8.1 was messed up. Obviously not an issue originating
> > from GnuPG. Apologies for the noise.
> 
> I ended up having this problem myself for the last few months. today I
> decided to look into it.
> 
> long story short a tickless kernel will make the agent wrongly detect the
> speed of encryption and thus it keeps incrementing the number of iterations
> sent to gcrypt lib function.
> 
> an upstream bug has been filed here: https://dev.gnupg.org/T3276

Thank you for debugging this and reporting it upstream