Thank you very much for your answer.
Unfortunately, I can't use --quick-add-key, because I believe the command generates a new subkey. What I'm trying to do is adding an already existing key as the subkey of a master key.

Please do not use addkey with in such a way. The use of "canned"commands way work now for you but can lead to unexpected results if anything changes, either due to changes in another gpg version or due to changes in your key etc.. The correct use requires a state machines along with --stattus-fd and command-fd. Because that is quite hairy to get right we have added a set of quick commands. In your case your should use

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.

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

I think the code is using https://en.wikipedia.org/wiki/Estrin%27s_scheme but I have no scholarship applying this to AES-GCM. I will have to look closer.

Thanks for prompt answer!

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

Still reproducible with current master of everything.

I had a quite old master of libgcrypt (probably from August 2). I'll update everything to master an retest.