Thanks for your report. This is because GnuPG 2.2.4 now requires newer libassuan (in order to fix a race condition).

Thanks a lot. I'm going to push the fix to 2.2 (and then master).
In short, it was the bug in ccid-driver of scdaemon, which was introduced last year when I enhanced it to support multiple card readers at once.

Thanks (again). According to the status code (bStatus), the card reader said no card is available.
Could you please remove the card and re-insert it, and do 'gpg --card-status'?

Thanks a lot for your testing. Please test this patch:

Thanks. I think that you configured GnuPG without libusb, thus, ccid-driver is not enabled, and you don't have pcscd installed. In this situation, no way to access any smartcard reader.

Please enable all debug information in scdaemon.conf, like:

verbose
verbose
debug-level guru
debug-all
debug-ccid-driver
log-file /run/user/1000/scdaemon-verbose.log

Thanks for your testing. please give me scdaemon.log with updated scdaemon.

OK. I realized that msgfmt -c only works when #, c-format exist.
To check all problems, I did something like following for 1.4, 2.0, 2.2, and master:

Thanks for the report. It seems there has been this bug for four years.
I don't know the reason why msgfmt -c doen't show us the error.
Fixed in repos of GnuPG 1.4, 2.2, 2.0 and master.

Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:

Please open another report, not reusing similar. I don't think it's same bug.
Please note that GnuPG's ssh is not fast enough (intentionally), its rate is usually ten connections per second.

Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)

Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?

Thank you for your cooperation.

For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.

Applied to libassuan master.

Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth

The patch above libassuan-hang-test.diff requires D455 and D456 applied.
I guess that without the patch for testing, current gpg-agent would just work fine, possibly. (no crash)

For better reproducibility of hang, this is more better:

To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:

For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.

I checked a card reader: https://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt

We had similar report back in 2015, but it was not fixed in GnuPG (possibly, card reader problem):
https://lists.gnupg.org/pipermail/gnupg-users/2015-September/thread.html#54345

It's in gniibe/scd-kdf-support.
I think it's good to add to GnupG 2.2 branch.

Applied.

Thanks everyone. I think that the problem is identified and fixed in libassuan.

Suppose a client which connects stopped task of server on Windows. In this situation, if the client blocks on closesocket, that is, some user space work is needed for server side for closing socket of client side, this bug can be explained.

If disable-check-own-socket can stop hanging, D454: assuan_close with nPth could be related.

If more fine-grained control is needed with suspend-to-ram, we need to write kernel driver for USB access.

I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.

I introduce GnuPG to my friend, yesterday. I saw this problem. It's on Windows 7, gpg4win 3.0.1 and enigmail.
Looking through this report, Windows 7 is common factor.

Another log is not needed, as I located the issue. If you can try building GnuPG from Git repo (it's 2.2 branch now), it helps us a lot.

There are multiple problems. I fixed one Makefile portability issue today.

It's fixed in master.
It is good to backport this to GnuPG 2.2 and GnuPG 1.4.

Applied to master already.

This is applied to master and 2.2.

Thank you for scdamon.log. For the card reader, the interrupt transfer notifies no availability of the card before PC_to_RDR_IccPowerOn.
I fixed this issue in rG0bb7fd0cab2d: scd: Enable card removal check after select_application.. Let's see if it works well for the card reader.

Fixed in 2.2.3 and master. Closing.

Fixed in 2.2.3, too. Closing.

Not yet located or identified the bug, but some information.

For some reason, scdaemon.log is not yet available here. Please put it again.

Applied to 2.2 branch.

Add the tag of npth (forgotten).

This is not an issue of GnuPG. Sorry.

No, I was not accurate. EXAMPLE.COM works, while example.com doesn't work.

I confirmed this is same bug in T2923: trust signature domain restrictions don't work, I am closing this one as duplicate.