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.

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.

Last week:

• Gnuk 1.2.16 release
• gpg: accepts Algorithm Information
• Learn about SAEAES (http://www.saeaes.net/), for possible use in Gnuk
  • easier to implement for MCU (than OCB), both for coding and licensing
  • one in the round 2 candidates of Lightweight Crypto : https://csrc.nist.gov/Projects/lightweight-cryptography/round-2-candidates

This week:

• Modify UI of gpg --card-status using Algorithm Information.
• T5063: Use of some "SCD" command through extra socket

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

Last week:

• In 2.2: T5039: 2.2.22 regression: Nitrokey Pro 2 is no longer recognized automatically, requires --card-status rG0a9665187a7c: scd: Fix a regression for OpenPGP card.
• scdaemon: Support version 3.4 DO 0x00FA "Algorithm Information"
• Examined the error path(s) for pin change
  • Confirmed that relevant information is passed to a user, although it's not always clear description for a user
  • Add missing error handling in Gnuk (to be 1.2.16)
  • In this investigation, found a minor problem in libassuan: T5048: Error handling in libassuan
• Build Gnuk with newer toolchain (of Debian "testing")
  • I learn again that newlib and gcc should be upgraded together (because of multilib change)

This week:

• Release Gnuk 1.2.16
• Some tests with GD32VG103 (the RISC-V version) to consider flash upgrade process in Gnuk
• gpg --card-edit/gpg-card checking "Algorithm Information" when it tries to change key-attr for newer cards

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.

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?

Topic:

• UTF-8 handling for LANG=C
  • In some situations, with LANG=C, some people expect UTF-8 (or no-translation) on POSIX, these days
  • With LANG=C, nl_langinfo (CODESET) returns ASCII (ANSI_X3.4-1968) (on GNU/Linux)
    • So, currently, it is handled as iso-8859-1 by GnuPG
  • In future, possibly, it would make sense to change behavior of this corner case, adding special handling of LANG=C
    • When LANG=C or LC_CTYPE=C is detected, it is handled as UTF-8, instead of iso-8859-1
    • Or, emit a warning that it defaults to iso-8859-1

Last week:

• UTF-8 things: T1514: charset weirdness with non-ascii User IDs under non-UTF-8 locales & T5038: UTF-8 handling in the command line
• For future development: T5034: dev: Deprecate libassuan-config, libgcrypt-config, ksba-config, ntbtls-config, npth-config, ang gpg-error-config
• Minor fixes & update
  • rPTH02ce6b2d27f9: Conditionally enable busy_wait_for.
  • rGd2f1a0a791db: scd: Add condition for VERIFY with 0x82.
  • rG9f148360a2bf: scd: Add heuristics to identify cardtype.
  • rE13c28a300e02: po: Update Japanese Translation.
• Other
  • Gnuk fixes for passphrase check

This week:

• Examine the error path(s) of UI of gpg --card-edit and gpg-card, so that it won't confuse users much.

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 )

Last week:

• It was too hot to work.
• Test with clang build
• Minor fixed in GnuPG master
• Minor fix in libgcrypt and libgpg-error
• Created T5029: server socket/pipe handling in GnuPG
  • Please note that it's not clean up for fd/HANDLE thing
  • It's a (minor) bug of calling close where we should use assuan_socket_close
• Defer working for FST-01SZ to September

This week:

• I realized that use of Linux kernel 5.7 is easier. Configure wireguard with Linux 5.7.
• Bug fixes