Both my coworker and I have the same issue. We just started using gpg for git commit signing. Works the first time. Then sometime later, no window pops up and will hang git indefinitely because it's waiting on the agent. Kill the agent and gpg process let git error out. try again, gpg-agent window prompting for password shows up and works.

The thing is that I don't see this bug with verbose logging enabled. So we need to do more code starring or instrument the code

Is there a more detailed logging that i can switch on? Perhaps i can help you to get diagnostic files. Nearly every day i notice this bug. In the log (with "verbose" in gpg-agent.conf) are the same entries i already posted.

I built gnupg 2.2.1 with the patch from D450, but that didn't help.
I even got an additional error:

Yes, it will be in 2.2.3. It's too late for 2.2.2.

So is 380bce13d94f the correct fix? If so, I will update the OpenBSD port including this as a local patch.

I believe this is due to the bug of gpg-agent. So, I put this report as a sub task under T3276: the calibrate_get_time() function depends on a system that has a non-tickless kernel.

This is a bug in gpg-agent.

Also failed to replicate on Windows-7 using a dedicated laptop.

I tested for several days with logging enabled but was not able to replicate it again. Then I tried again w/o logging and couldn't replicate it either.

We can't change that anymore. So the question is how and whether to fix it. Right now gpgconf --list-dirs has no need to ask gpg-agent for the actual socket and it would be a catch-22 anyway. Thus to fix this we need to parse the gpg-agent.conf in gpg.conf directly.

I can replicate this now. Unfortunately without logging enabled.

Here is a part of the log inline:

Hello.
I am having the same problem with my Yubikey v4.

... gpg-agent hangs. After cancelling the process it works again ...

Sorry, I haven't waited long enough.
It's happened again. After leaving Thunderbird open for a while, when consulting another encrypted email, the window asking for the password does not appear and does nothing.
I need Gpg4Win, I'm going back to Gpg4Win 2.3.4

I think it might be a cleanup problem.
If you uninstall Gpg4Win 2.3.4, restart the computer, and then install Gpgp4Win 3.0.0, everything works correctly.

gpg-agent.conf actual content:

Does anyone of you have a gpg-agent.conf and if so, what options are set?

It works correctly when installed and executed.
After a period of inactivity and with Thunderbird still open, it stops working.
With Gpg4Win 2.3.4 it works correctly.

For context, here's what the wisdom of the crowd is rigging together around GPG to get this single-sign-on feature:

Just to inform that it is not a single problem.
I recognized exactly the same behaviour.
After terminating the gpg-agent task everything works as aspected (up to the next non-activity phase).
64-bit Windows 7 Enterprise, Outlook 2010, GPG4Win Version 3.0.0-gpg4win-3.0.0.

I think this is now resolved, as of rG926d07c5fa05

The only mitigation I can see for this is a better error message.

Given no feedback, I'm closing this issue.
If there is still problem, please reopen.

In fact, on Windows you would need to have a system service. We did this in the past for the dirmngr but remove that feature due to possible security problems and problems during installation.

That is correct, gpg-agent does not daemonize on Windows if --daemon is given, it is simply not implemented.

GnuPG 2.1.22 in Homebrew is out: https://github.com/Homebrew/homebrew-core/commit/39a392ffd6ac20a36ea8a4aec5c4dc5febcfc1d6
Please check it out.

I am not to familiar with the gnome keyring but from looking it up on the arch wiki, it seems to have this single sign on capability.

So this is basically 0what GNOME does with its keyring daemon and pinentry-gnome.

Btw, this was envoy: https://github.com/vodik/envoy

what I mean by unlocking is the act of using the passphrase to load the gpg and ssh keys and hence not needing to tip the phrase again afterwards.

I don't understand what you mean by unlocking gpg-agent. Can you please explain in detail what you try to achieve.

Sorry, I went through considerable length to reproduce this, but failed.

@marcus sure, but I am currently away on vacation and won't be back until mid August. Also, I'd need some detailed build instructions (I'm on mac os) since I'm not very familiar with building C code - I brew installed gpg.

Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053

Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.

This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.

@landro Would you like to do one more round of testing?

Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.

I don't think we want any behavioral changes to gpg 1.4 anymore. And in gpg2 all of this is different (use-agent is mandatory, passphrase-fd only used with batch).

No response.

FWIW, I ran a make check today and got several failed tests when using the extended key format. Checking out master to see whether this was caused by another patch I am working on, showed that it worked on master. Checking out my local branch again, then passed the test.

Still, looks totally fine to me:

In T3187#98531, @werner wrote:

I will try to reproduce it. It might be that --passwd also trigerred the conversion to the new format.

I will try to reproduce it. It might be that --passwd also trigerred the conversion to the new format.

Odd, I cannot reproduce this:

I released libgcrypt 1.7.7
and nPth 1.6

libgcrypt secmem fix is not that in hurry, I think. nPTh bug for macOS sounds more severe.

So, should we do a new libgcrypt release RSN?
There is another bug with solution also pending and it might not be too late for Squeeze if we hurry.

I managed to replicate this issue by preparing artificial nPth on x86 GNU/Linux.

I fixed a bug in nPth: rPTH4fae99976c31: Fix busy_wait_for.
During this debug, I also found a bug and fixed in libassuan: rA62f3123d3877: Use gpgrt_free to release memory allocated by gpgrt_asprintf.
Also, I fixed two related bug in GnuPG:
rGc03e0eb01dc4: agent: Fix error from do_encryption.
rG996544626ea4: agent: Fix memory leaks.

@gniibe , I'm not setting the max-passphrase-option. Currently, my gpg-agent.conf looks like this:

@landro , Do you have any key which might require passphrase update for its expiration?
I mean, do you have an gpg-agent option of "max_passphrase_days" set (default is not set).

(Since I was writing by phone, the sentence was terse. Sorry. This time, by PC.)

What do you mean by connection error, @gniibe? I hope the user is not impacted by what you are suggesting.

For smartcard, yes. The feature for ssh with smartcard has been available more than ten years. I recently apply the approach to gpg frontend.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

Just noticed one more thing - I'm not trying to use a smartcard at this time (I plan on moving to yubikeys in future though) - why is "new connection to SCdaemon established" all over the logs?

So I'm using pinentry-mac in my gpg-agent.conf:

So I noticed your log contains lot's of "starting a new PIN Entry", I assume you are using some kind of password manager integration, so that you don't need to enter it each time (sorry, I'm not familiar with how pinentry works on macOS).

Ok. To reproduce, I believe the key is to establish lots of connections (in my rig around 20) to (possibly different) ssh server(s) (possibly by going through a bastion) within a short timeframe.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

Too bad. I installed both libgcrypt and gnupg using homebrew, and apparently there is no way to make homebrew include debug info. I guess I could build from source and include debug info - where can I find instructions on doing that?

Hm, it did not give us the location in the source unfortunately, only
the offset from the top of the function, which the original stack trace
already contains. Maybe the library does not contain debug information.
Depending on how you installed that software, there may be a way to
install the debug symbols too. That would make bug reports much more
helpful. Thanks anyway, maybe the log will help us trace the problem.

"landro (Stefan Magnus Landrø)" <noreply@dev.gnupg.org> writes:

In https://dev.gnupg.org/T3027#97654, @justus wrote:
> Hi @landro, thanks for the stack trace.  Could you please try to resolve this frame
>
>   4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

Here it is. @justus

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2
openpgp_s2k (in libgcrypt.20.dylib) + 594

@landro Thanks a lot. I think that we see some failures in the log, and there might be another bug in the failure path.

In T3027#97654, @justus wrote:

Hi @landro, thanks for the stack trace. Could you please try to resolve this frame

4   libgcrypt.20.dylib            	0x000000010d8b14d2 openpgp_s2k + 594

to a source code location? I believe it can be done this way:

$ atos -o /usr/local/opt/libgcrypt/lib/libgcrypt.20.dylib -arch x86_64 -l 0x10d896000 0x000000010d8b14d2

I tried to reproduce this issue locally but failed.

Here is the output of the log file