I put an entry: https://wiki.gnupg.org/SmartCard#Known_problem_of_Yubikey

After resume, because resume is not detected, some user interaction is required to cause an error.
gpg --card-status (which will only show partial information) is enough. Or, ssh failure. After failure, scdaemon reconnects the token.
Then, you can use it again without plug-off/plug-in.

Thanks a lot for pointers and suggestion.
Well, the problem of Yubikey itself cannot be solved by others, we can put some workaround for the error recovery.
So, this is another try of mine to improve error recovery.

Part of the problem is Yubikey side, I suppose. (Because my implementation of Gnuk Token has no problem for suspend/resume if it's in-use.)

Again, thanks a lot for your testing. The log said: The code I added cannot detect the event of suspend/resume.
It seems that there is no way to recover from suspend/resume for Yubikey.

Thanks a lot for your testing. So, apparently, the PC/SC behavior is different between GNU/Linux and Windows.
Thus, I pushed another change: rG1e27c0e04cd3: scd: More fix with PC/SC for Windows.. Please test this. (Both of previous version and this version work well on GNU/Linux for operations not including suspend/resume with Yubikey and Gnuk Token, while my Yubikey with PC/SC doesn't work well for suspend/resume.)

Sorry, my build was not good even if it's for x86_64 (I used development version of libassuan, etc.).

I realized that: once KDF-DO is written to smartcard/token, factory-reset command won't work because it assumes standard PIN format than hashed.

Sorry again. My script was still wrong (didn't work).

It doesn't work because I did mistake for the salt of reset code, it should be 8-byte instead of 4-byte.
Here is a fixed version, which I tested with Gnuk 1.2.8:

If possible, please try with this (patched version of scdaemon):

Something like this script should be implemented by gpg frontend:

I realized that suspend/resume is not supported yet on GNU/Linux: https://anonscm.debian.org/cgit/pcsclite/PCSC.git/tree/TODO#n7
So, I can't test myself.
Here is an attempt to improve:

It looks like SCardGetStatusChange doesn't return failure after wake up.
Here, what we need is catching the event of wake up, which requires reset of the card.
I think that we can check by the dwEventState field.
I'll try on GNU/Linux environment, then ask you to try.

It's in GnuPG 2.2.4, now.

It's a bug in the OpenPGP card implementation.
I put an entry in Wiki: https://wiki.gnupg.org/SmartCard#Known_Bug.28s.29_of_OpenPGPcard

The error of testQuickUID is strange. In the test, it adds a UID and checks number of UIDs (3 + 1 = 4).
It is not reproducible for me (Debian with Qt 5.9.2, NetBSD 7.0.2 with Qt 5.5.1), gnupg 2.2.x from the repo.

I guess that you are running on 32-bit architecture where the function keybox_get_keyblock uses 32-bit signed size_t for image_off and image_len.

Fixed in rGca138d5bf36a: gpg: Fix reversed messages for --only-sign-text-ids..

Thanks for your report. I'm going to fix the messages.

I believe that all BSD Makefile issues has been fixed (except python-tar-gz distribution thing for maintainer).
Please test again.

I located the problem. It's Makefile portability issue and it is fixed in: rMb5ec21b9baf0: tests: Makefile portability., rMba6e610baa13: tests: More Makefile portability., and rM3224d7f0ea83: tests: Fix previous commit
It was not your final invocation of "make check" (GNU or BSD), but the one before ("make all" by BSD make) which imported keys for tests.
The "export" directive doesn't work on BSD.

OK. Then, it may be some bashi-ism in Makefile. I'll investigate with no bash installed.

For other failures, I guess that you are connecting your card, aren't you?
Last year, I introduced a change for key selection to prefer existing card key. That may affect tests. Well, tests should have configure not to try to access card.

HAVE_PSELECT_NO_EINTR is introduced for systems which pselect cannot be interrupted.

I think that it's the kernel problem in NetBSD, where signal to self cannot result EINTR for pselect.
Well, something like rG031e3fa7b9a6: scd: Wake up the select when new USB scan. can be applied, I suppose.
Let's see for configure.ac and HAVE_PSELECT_EINTR.

For scdaemon process(es), I created a ticket T3778: NetBSD: scdaemon should be killed when its parent (gpg-agent) is going to shutdown.

Thanks for your additional suggestion. I pushed the change.

For BSD Make issue, please try:

Ah, yes. Will do. Thank you for reminder.

Thanks for the report.
Fixed in master.

For the latter, I think it requires path to moc, which may be like /usr/pkg/qt5. Please add it to your PATH. Then, retry from configure

Fixed in rM37d62e9d0f68: core: Implement _gpgme_getenv for NetBSD..

Other problems are fixed. Please test. It works for me on NetBSD 7.0.2.

I push my change to master.
Please test.

Thanks for testing master.
No, it's not typo, in my opinion.
The line was added as if it's LOCAL_PEERUID, but there is no such a thing in XNU, but there is LOCAL_PEERUUID which is for UUID.

You can compare your key with a key generated by GnuPG.

I use Debian stretch. It works for me with GnuPG 2.2.4.
The stub is created at the time when --card-edit accesses the card.
When I type RET after fetch command, it shows the key information.

It is reproducible on my Debian (stretch). I'm going to minimize the case.

@werner It's just simple; With --personal-cipher-preferences 3DES (3DES only), make a encrypted message. Then, try to decrypt the message with OpenPGPcard (version 2.1 and later).

I forwarded the bug report to the OpenPGP card author.
I think that 2.0 card is OK, 2.1, 2.2, and 3.3 card have this bug.

OK. I managed to reproduce same behavior. I think that it is a bug of OpenPGP card implementation.
Here is the log:

Could you please give me the debug output line for DEK frame: by encrypted mail to me? So far, I can't find any likely scenario where an error occurs with smartcard. (Use of PGP2.6 is unlikely.)

The conformance problem may (only) happen between PGP 2.6 and OpenPGPcard, because PGP 2.6 uses old format not compatible to PKCS#1, but OpenPGPcard requires PKCS#1.

OK, I got the picture, now.

Well, my speculation of SERIALNO undefined may be wrong.

Thanks, I received the log file.

Thanks a lot for your testing. Here are my keys: