It seems to pass for me with gnupg-2.2.41 but fails with gnupg-2.2.42?

T4820 is not related (it's a failure of t-keylist-secret in t-json), while this is failure of t-decrypt.

You can get more information by applying a patch below (and also tests/json/Makefile.in):

diff --git a/tests/json/Makefile.am b/tests/json/Makefile.am
index 90fba79e..7523bb6b 100644
--- a/tests/json/Makefile.am
+++ b/tests/json/Makefile.am
@@ -106,6 +106,8 @@ gpg-agent.conf:
 # a key from a smartcard reader (error might be: Unusable secret key)
 	echo pinentry-program $(abs_srcdir)/../gpg/pinentry > ./gpg-agent.conf
 	echo disable-scdaemon >> ./gpg-agent.conf
+	echo debug-all >> ./gpg-agent.conf
+	echo log-file /tmp/gpg-agent-logfile.log >> ./gpg-agent.conf

 
 # end-of-file

The gpg-agent log will be available at /tmp/gpg-agent-logfile.log and we will be able to determine the reason why no secret key.

Although I don't think this is the case here one should be aware that tests mail fail due to global configuration of GnuPG (/etc/gnupg/*.conf). There is no easy way so solve this except for running a per-test local installation of GnuPG using the gpgconf.ctl feature.

Ah, thanks Werner, I'll keep that in mind.

Here's the /tmp/gpg-agent-logfile.log file:

Thanks a lot for your quick testing.
The commit rGff42ed0d69bb: gpg: Enhance agent_probe_secret_key to return bigger value. of GnuPG 2.2 introduced this bug.

It now uses KEYINFO command, but for gpgme JSON use case, gpg-agent is restricted.
Thus, something like this to GnuPG 2.2 is required:

diff --git a/agent/command.c b/agent/command.c
index 2e1d820ba..940e017d8 100644
--- a/agent/command.c
+++ b/agent/command.c
@@ -1282,9 +1282,6 @@ cmd_keyinfo (assuan_context_t ctx, char *line)
   char hexgrip[41];
   int disabled, ttl, confirm, is_ssh;
 
-  if (ctrl->restricted)
-    return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
-
   if (has_option (line, "--ssh-list"))
     list_mode = 2;
   else
@@ -1333,6 +1330,9 @@ cmd_keyinfo (assuan_context_t ctx, char *line)
       char *dirname;
       gnupg_dirent_t dir_entry;
 
+      if (ctrl->restricted)
+        return leave_cmd (ctx, gpg_error (GPG_ERR_FORBIDDEN));
+
       dirname = make_filename_try (gnupg_homedir (),
                                    GNUPG_PRIVATE_KEYS_DIR, NULL);
       if (!dirname)

No, thank you both for the speedy responses :)

Pushed the change in: rGf50c543326c2: agent: Allow simple KEYINFO command when restricted.

In 2.4 we have rG1383aa475 which does

• (cmd_keyinfo): Change semantics to return nothing in restricted list mode.

Shouldn't we check whether we can do the same here. In any case I am not sure whether we should really do anything here because this works in the stable version (2.4) and gpgme-json is not a use case for the legacy version 2.2.

Thanks, that patch works for me.