Hi Zetrick,

Perhaps, don't allow automatic use of available card keys would be better:

diff --git a/agent/command.c b/agent/command.c
index 160979dae..b6286becf 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -2292,13 +2292,7 @@ cmd_scd (assuan_context_t ctx, char *line)
       if ((argc == 1 && !strcmp (argv[0], "SERIALNO"))
           || (argc == 2
               && !strcmp (argv[0], "GETINFO")
-              && !strcmp (argv[1], "version"))
-          || (argc == 2
-              && !strcmp (argv[0], "GETATTR")
-              && !strcmp (argv[1], "KEY-FPR"))
-          || (argc == 2
-              && !strcmp (argv[0], "KEYINFO")
-              && !strcmp (argv[1], "--list=encr")))
+              && !strcmp (argv[1], "version")))
         xfree (l);
       else
         {

This is due to access control for "extra" socket.
Fixed in T5062: gpg: error getting version from 'scdaemon': Forbidden.

Hi all, I have this issue in Win10 in correct installation. Si I am interested what can I do to repair this issue. GPG is working correctly, but Kleopatra's selfcheck show this issue. Thanks. Portug

OK I found a very interesting thing here, @werner and finally I can reproduce this problem:

That is a version of gpg4win which we don't support or even know about. Please ask at their support site. Sorry.

Thanks for the report. Indeed, the convenient C99 feature of variable definition in a for statement does only work in recent gcc versions and thus it should not be used in GnuPG related code. (https://gnupg.org/faq/HACKING.html was out of sync with the version in gnupg's master repo which falsely stated that it is an allowed features.)

The name field is marked as optional but it is mandatory. This should be fixed.

Thinking that maybe the gcc version is too old I tried using instead CentOS gcc7 development environment (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5) (which doesn't come out of the box). This was an educated guess as c99 is only partially supported in gcc-4.8.5. I have now successfully built:
libgpg-error-1.39
libassuan-2.5.3
gpgme-1.14.0
using gcc 7.3.1. All make check tests have passed.

The json problem can be overcome by changing the configure line to:

Actually I don't use systemd unit to start gpg-agent (creating that service file in systemd and make it start automatically) but I run it manually within the script. Also the script has selfcheck not to run multiple gpg-agent like below:

We encountered the same issue today, and below is the debug messages. It works as expected once we downgraded to 2.2.21. We're on Arch Linux.

Version 2 is a bit too unspecific. Which version of what software are you using. Which OS?

Good catch. Thank you.

Hi,
I corrected all the accents. I created a PR here https://github.com/gpg/gpg4win/pull/3

Any ideas? Is there any other info needed that could help move this along?

There is a conflict between the systemd based launching of gpg-agent and gpg's own launching of the agent. Further systemd seems to remove the /run/user/UID directory which unlinks gpg-agent's socket. gpg-agent's self-check notices this after a minute and termintates itself.

I think that rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixes this issue.

I observed that the card reader's going erroneous state when I removed a card during its communication.
In this state, it never reports the card removal by the interrupt transfer.
I applied rG920f258eb601: scd: Internal CCID driver: More fix for SPR532. for this problem.

Great, thank you @gniibe.

Thanks for your report.

Update found out the answer for this mystery but I need to know why from you guys:

With all respect. Should I wait for a follow-up or I should consider this case as closed?

With 2.3 we add the keyboxd which uses sqlite (and thus indices) as database. This makes lookups much much faster and avoids problems with several processes accessing the pubring.kbx. If you want to try this you can do so with 2.3:

The patch rG684a52dffa8b: scd: Change handling of SPR532 card reader. makes me happier. It is more stable.

This is also what I found out with my tests with the libvirt usb: removing and redirecting back the device got it working again.

Testing more, I managed to encounter failure with physical usb.
Once in this failure mode, I need to remove the card reader from USB and reinsert again.
I need to figure out a sequence to avoid this situation and to reset the card reader correctly.

I tested with physical usb, did multiple operations with external events (insert/remove/etc. for card). I haven't seen any problem (if so, I were doing more fixes), so far.

That code in gnupg has not been touched in a very long time so this may be caused by some side effect.

Ok. Tried to test this with master, but failed. I got it compiled and installed, and it actually detected the first removal after reboot/suspend/reader attach/whatever reason, but after that when I inserted the card back, it didn't function anymore. I suppose you also tried that? I mean that's the use case, I suppose: to be able to remove/insert the card reliably all day long.

Currently, yes. After some testing, I'll backport it to 2.2.

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.