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

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.

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

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.

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.

Thanks for sending.

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

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.

Sorry, my editing error. I wanted to write:

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.

The data object 0x00FA is now supported. And other changes are not needed.

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.

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

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.

Thanks for your information. No debug output any more, as I already figured out things.

Well, from the viewpoint of card specification, "a message M of arbitrary size" for Ed25519/Ed448 in RFC8032 is not good, because card has a limit for buffer size and the protocol in the OpenPGP card specification requires the steps of (1) the message M is buffered and then (2) the compute the signature.

It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.

I just confirmed that Gnuk has a limitation for the input length is less than or equals to 256.
So, this is the issue of Gnuk, not GnuPG (or at least, Gnuk has the problem).

Please show us concrete example of debug output by scdaemon, when you run ssh-keygen.
You can have a setup in .gnupg/scdaemon.conf like:

Thanks a lot. Applied and pushed.

I think that following patch can solve the issue:

Ah, I see the situation of the regression.
When the token is not yet accessed at all, scdaemon misunderstood as no signing key.

Do you have a signing key in your card or not?

I mean:

diff --git a/common/utf8conv.c b/common/utf8conv.c
index 7804dbfcd..bdab225a9 100644
--- a/common/utf8conv.c
+++ b/common/utf8conv.c
@@ -138,7 +138,7 @@ handle_iconv_error (const char *to, const char *from, int use_fallback)
          native encoding.  Nowadays this seems to be the best bet in
          case of errors from iconv or nl_langinfo.  */
       active_charset_name = "utf-8";
-      no_translation = 0;
+      no_translation = 1;
       use_iconv = 0;
     }
 }

In T4977: dirmngr not working with linux kernel parameter ipv6.disable=1, EAFNOSUPPORT fix was applied in 2.2.22.
I think that original problem in this report is fixed.
Please test with 2.2.22.

Actually, configure already has the check.
If it's really needed to build without zlib, you can use this patch:

From 76920ac034490e4860ad6abe9891e3b1c0813363 Mon Sep 17 00:00:00 2001
From: NIIBE Yutaka <gniibe@fsij.org>
Date: Fri, 28 Aug 2020 11:02:13 +0900
Subject: [PATCH] Until compression is implemented, build with no ZLIB can be
 done.

It's pretty minor bug, it only matters for some strange scenario on Windows like:
(1) a user runs gpg --card-edit or gpg-card and keeps the user interaction for some reason (say, forgetting the terminal interaction), which keeps the pipe connection from gpg-agent to scdaemon
(2) While the pipe connection is used by the user interaction above, from another terminal, the user invokes gpg (say, gpg --decrypt) which uses socket connection from gpg-agent to scdaemon

I mean these uses of close:

diff --git a/scd/scdaemon.c b/scd/scdaemon.c
index b7bbc0361..a6925eaf9 100644
--- a/scd/scdaemon.c
+++ b/scd/scdaemon.c
@@ -797,8 +797,8 @@ main (int argc, char **argv )
       /* We run handle_connection to wait for the shutdown signal and
          to run the ticker stuff.  */
       handle_connections (fd);
-      if (fd != -1)
-        close (fd);
+      if (fd != GNUPG_INVALID_FD)
+        assuan_sock_close (fd);
     }
   else if (!is_daemon)
     {
@@ -932,7 +932,7 @@ main (int argc, char **argv )

No more information, can't proceed, thus, closed.

For GNU/Linux, it's done.