I am sorry, but this is a bug tracker and not a help list. I don't even known what Electrum is. Please ask at their support site or if you are looking for general help with GnuPG post to the gnupg-users mailing list (see https://gnupg.org/documentation/mailing-lists.html)

I also don't want to leave my card in the reader authenticated for a full day, it just doesn't sound like a good practice to me. I also very often just forget about the card, so it just sits there, keys open for use.

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

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

Last week:

• Looked into LDAP problems
• gnupg.com work

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

Last week:

• Fix for KDF handling among different implementations (Gnuk, Yubikey, and Zeitcontrol)
  • Basically, Zeitcontrol requires special handling
  • only for master
• Extra socket use in master: T5063: Use of some "SCD" command through extra socket
• Suggest for a use case of token for a remote machine from local notebook
  • T5062: gpg: error getting version from 'scdaemon': Forbidden
• Realized that UI for key-attr is a bit complicated
  • Perhaps, it's best to keep information for cards/tokens in scdaemon while gpg/gpg-card just offers UI

This week:

• Off for Monday and Tuesday (except the telco)
• Key attr algorithm information in scdaemon
• T5065: scdaemon doesn't detect card removal after boot/resume (Identiv SPR332v2)
  • I guess that it's an issue around the interrupt transfer (and its behavior at computer reboot)

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.

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; 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 openned 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.

I checked two devices and both have the info below but 332 on the case.

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.