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.
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.
(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 ?
(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
Created attachment 449358 [details] emerge --info gnupg npth libassuan libgpg-error libgcrypt pinentry libksba
Created attachment 450206 [details] build.log with FEATURES="test" I experience the exact same issue. Therefore I'm attaching the requested information.
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.
Created attachment 450210 [details] emerge --info gnupg
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.
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!
I am using 4.4.8 and it looks fine.
(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.
(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.
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.
(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
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.
with FEATURES=test gnupg still hangs.
(In reply to moikkis from comment #16) > with FEATURES=test gnupg still hangs. Please open a new bug with sufficient information to debug
(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
(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
(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
