I pushed the change to master.
Please test.

Please consider to backport rG914fa3be22bf: dirmngr: Support the new WKD draft with the openpgpkey subdomain. from master. Cherry-pick mostly works, only dirmngr/server.c needs manual edit (because of resolve_dns_name change).
Allowing WKD service by subdomain (openpgpkey) is good, because it is easier to deploy by separate admin, in some situations.

I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.

When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.

Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).

No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.

Let me explain some technical detail for the record.

Because my fix was incomplete, I pushed another change to GnuPG master: rG374a0775546b: agent: Close a dialog cleanly when gpg/ssh is killed for CONFIRM.
I also pushed my changes to pinentry master: rPf6e84ce0a34c: tty: Confirmation is not by line edit mode., rP531b92300c58: tty: Support line editing by system., rPb176a8ac0dcd: Exit the loop on an error with GPG_ERR_FULLY_CANCELED.

Thanks a lot. I was not careful when I updated.
Along with the error you addressed in the patch, I also found another.
All fixed in rGf05fd37266f5: po: Update Japanese Translation..

I meant, GnuPG side was fixed in master, it sends SIGINT to pinentry process when gpg exits.

Ah, yes, that signal thing should be handled correctly, when we support line edit by tty.

(What you see as the link addressed in 2015 is for pinentry-curses, which is irrelevant.)

Thanks for your review.

It works for me.

@dkg, for your patch, it can be improved for Windows by using its event mechanism. You can see gnupg/scd/scdaemon.c.

There are two different cases: (1) By SIGTERM and (2) By KILLAGENT. It's true that the agent stops accepting on the listening socket for (1), but it's not the case for (2).
This particular problem is for the case (2).

Thanks, that's a good point. I'm adding gcry_ecc_get_algo_keylen.
I also changing the API for output (not allocating a buffer, but filling the buffer provided).

Correct solution is to implement KILLAGENT synchronously, but it's somehow harder to implement.
Easier workaround is modifying gpgconf like:

I found a race condition between KILLAGENT command and accepting another request.
Here is a patch to replicate the race condition :

I took this task as it has errors of gpg-connect-agent scd killscd. But, it seems for me that it's not the direct cause.
Anyway, I investigate the bug.

Perhaps, returning allocated memory is not good. Filling the buffer for output would be better.

Shall we use secure buffer?

Fixed in master, by using /usr/xpg4/bin/sh on Solaris.
Perhaps, some old Unix system like Tru64 would need same care.

I wrote the script and the intention is supporting old systems using POSIX shell. Our goal here is: Not introducing (additional) dependency to Bash.

Fixed in master.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

Fixed in master. Closing.

Fixed in master (to be 2.3).

I tried to apply&push, since we changed the file a bit, I needed to apply it manually.
Anyway, it's done.
Closing.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

While it's not recommended, current master has a support of sharing same raw key materials. I think that it now works (I don't try, though).
Closing.