Nice, thanks! If I want to try this fix, should I just compile the master tree?

Update: Using --use-standard-socket argument to run this does not work and gpg-agent still create new process. New findings:

Just to acknowledge here: I notice that the new gpg-agent random process respawn with an obsolete argument using --use-standard-socket. I will run my gpg daemon using this absolete argument to see if it can block this random process. [updated the script]

Thanks for your reply. I can confirm from my observation from the log this is a bug where I'm able to reproduce this every day. I will post this to mailing lists.

I tried using the portable version it wasnt portable apps, i used it the zip file option from this site, https://portapps.io/app/gnupg-portable/

FWIW: You may get a faster answer if you post to gnupg-users mailing lists. Bug reports are a tool to fix bugs and usually are only seen by a few developers.

I'm now able to kill the respawn process in the script (updated the script). But I need confirmation if this is a known bug ?

I can create a script to manually kill the 2nd process, but can u guys confirm with me that this is a known bug ?

Just to let you know that , using --homedir option also has the same problem I noticed today. I got email each minute like this:

Ok let me update what I did next:

Here are my test configurations.

I think that there is some misunderstanding how gpg-agent and scdaemon run.
In the normal configuration, those program run when you login to your desktop or it is invoked when used, then, after you logout, it dies.

For SSH, I don't think forwarding gpg-agent's socket (S.gpg-agent.ssh) is good idea; It complicates things unnecessarily. Simply use -A option of SSH, if possible.

Fixed in master.

"SCD GETINFO card_list" is not needed actually. It was my misunderstanding.

Last report more than two years ago.

This is everything lsusb knows about the device:

And please report the output of lsusb -d 04e6:e003 for the information of the card reader.

@turkja Thanks for your information.
May I ask you one thing?
Please show me the usb VID:PID of your card reader.
Is it 04e6:e003?
You can examine a line of the output by lsusb.

Just wanted to add to my initial findings:

• I was not using proprietary drivers (libscmccid.so.5.0.35), because the installer script fails to install on default CentOS 8 pcsc-lite. So the distribution pcsc-lite also doesn't have this issue.
• Fastest way to test this condition is to just detach/attach the reader device.
• Proprietary drivers doesn't support secure pin entry!

Please note that:

• There is a single user accessing the socket dir (which is the same as the homedir).
• The socketdir (homedir) is not in a local directory. It is in another file system accessed via the SMB protocol, with a command such as:

gpg --homedir "//192.168.32.211/c$/gpghomedir" ...

From the '&ovl' I assume that the lock file has been opened for overlapped IO.
Please see an extract from MSDN for the LockFileEx function:

We need to figure out why the file locks seem not to work. gpg-agent processes whatch there own socket and terminate if that socket does not belong to them anymore.

Thanks for sending.

Here is the output for an SCM SPR532

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

Is it an alias of SPR532? Please show me the USB vendor ID and product ID.

Yes it is the windows version. It occurs both in Windows 10 and Windows Server 2016.
What I notice is that a gpg-agent is started, then after some time another one is started and the previous ends (presumably because it has lost the socket), etc. At any point in time, I can see only one agent instance running in the task manager, but with different process ids.

Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

I assume this is the Windows version. gpg uses a locking mechanism to avoid creating several gpg-agent processes. In the worst case this may take quite some time until one of the processes can get the lock. There is an exponential backoff scheme in use and I have not yet found a way to replicate the full deadlock you describe. It would be helpful if you could describe in more detail how you run into this case.

Thanks for prompt answer!

Thanks for the detailed report. Does the green LED blink fast when it does not work?

Additionally, does your answer imply that when I ssh into remote, no gpg logs on remote should be produced if everything is executed correctly?

I see. How should I prepare environment instead? With local it is clear, but with remote it isn't. I also use remote as a normal machine with yubikey plugged directly into it most of the time, as it is a desktop at home. Local is a laptop that I use when I'm not at home. So, let's say I have a fresh reboot of remote and use it a bit with yubikey. So, it has gpg-agent started with its own socket there. Now I want to ssh into remote. If I understand correctly, for correct functionality I need to kill gpg-agent on remote first, otherwise agent forwarding will misbehave? Then, after I'm done with ssh and get back to remote (physically), how do I "recover" from ssh and re-launch gpg agent normally again? Since you say that killing it will send instruction to kill it on local machine, what should be done instead?

You should not do gpgconf --kill all on your remote machine; It kills gpg-agent on your local machine, through forwarded socket. And next invocation of gpg will invoke gpg-agent on your remote machine, which makes things confusing.

I didn't run gpg-agent or scdaemon on remote manually. If that happened -- it probably happened as a result of ssh'ing into it and spawning a zsh shell, which executed the section that I mark as "Environment (per shell)" above. I do this kind of "preparation" (stop gpg, clean up logs to collect only relevant logs on problem demonstration) to make the problem description as minimal as possible. And I post all relevant produced logs to make the problem description as complete as possible. Sorry if this is confusing, I don't really know what I'm doing but I want to make a bug report that can be acted upon.

Sorry, my editing error. I wanted to write:

Thank you for the response.

Perhaps, for the usability, it would be good for gpg-agent's "extra" access to allow some of SCD commands.
This can align the current limitation, I suppose.

I think that your configuration does not work well for gpg --card-status when you want to use local scdaemon service from remote machine.
By using "extra" socket, only a few commands are allowed to execute.

Fixed in Gnuk 1.2.16, although it still has a limitation by the I/O buffer size.

It should be possible to apply the patch rG7de9ed521e516879a72ec6ff6400aed4bdce5920
for 2.2 also to older 2.1 or 2.2 versions,

That keeps the group permissions of an existing directory. Needs to be backported to 2.2

The fix we have there has the problem that it forcefully changes the permissions. Consider the case that for example that group access was provided which will currently be reset with each start of gpg-agent.

There are two problems that might be mixed in here:
What I noticed sometimes is that pinentry-qt properly becomes the ForegroundWindow but the input focus is not set on the line, even though an active cursor is shown in the line.
This might be a pinentry-qt specific issue and I look into that.

@gniibe I wonder, if file --export with following --import would do the trick!?

Checkout the taskbar. While creating the key you should get a (blinking) notification for pinentry - the tool to enter the passphrase. Under some circumstances Windows won't pop up that tool and you need to click on its icon in the taskbar.

@gniibe: Actually I implemented this recently. Support for this is in gpg-card

@leder I agree that it is useful if OpenPGP public key can be (directly or indirectly) retrieved from a card.

One more idea: It is a riddle to me why I can configure keyserver http://pool.sks-keyservers.net/ and then do a --search-keys, but it is impossible to do --receive-keys with the following error:

Thank you, gniibe!

I have run the DbgView test twice, I don't know if there is the data you need.

Please note that your private keys are on your card, together with finger print information. But there is no place to have OpenPGP public keys on the card. I guess that this is a possible cause of confusion.

Now I am even more confused! This is key No. 1 - the number on the keyserver w/ --search-keys:

On an OpenPGP card the key no 1 (OPENPGP.1) is a sign-only key - you can't use it for decryption even if you somehow managed to encrypt to that key. That restriction is enforced by the card.

thanks for the report. Between Gpg4win-3.1.12 and Gpg4win-3.1.11 KF5ConfigWidgets was indeed updated so your report might point to a regression in that library.

Hello Werner,

Your problem seems to be that you don't have a copy of your public key anymore. The uni-mainz keyserver might be configured not to return expired keys (if I read the output above correctly). I was able to to retrieve your key using the standard pool (in particular from the server sks.pod02.fleetstreetops.com). The key is expired but that does hinder you to decrypt. Run "gpg --card-status" once tomake sure a stub file is available.

Now I changed the gpg2 keyserver and can see my public keys on the public key server: