I checked the development log for the addition of:

libusb_clear_halt (handle->idev, handle->ep_intr);

In T5167#139966, @gbschenkel wrote:

I have another yubikey neo but its clean. Can it help it?

In T5167#139964, @gbschenkel wrote:

Changing modes will I lose/change my OTP and FIDO codes?

Following device (a bit older than yours, I guess) works well:

DBG: ccid-driver: idVendor: 1050  idProduct: 0112  bcdDevice: 0334

When I configure it to OTP+FIDO+CCID, it also works for me, it is:

DBG: ccid-driver: idVendor: 1050  idProduct: 0116  bcdDevice: 0334

Pushed the change by Ingo.

I finally recognize this change: rG638526d37fee: agent: Allow signing with card key even without a stub key..
I should have seen this yesterday.

Thanks a lot.
Let me explain the situation.

Thank you for the information.
In the log, the driver detects removal of card wrongly.
That's the cause of this problem.

Pushed in rE9ee011259f81: build: Use AC_CHECK_TOOL to detect objdump for cross build..

Thank you. I'm going to apply it, modifying a bit.

I think that the semantics of gpg --quick-gen-key <KEY> card (currently) assumes keys are available on card.
IIUC, it is for some specific (very special) use case to specify same key creation time to the key on card.
I don't know well about this use case.

Please show us the output of gpg --card-status, and your configuration if you have something special. Are you using Yubikey also for gpg's signing, or is it only for SSH?

Backported.

We need another patch, because there are two places for gpg --card-edit and gpg-card to check OpenPGPcard's version number if it's >= 2 or not.

In T2291#139821, @lopter wrote:

if I am running master, it is now possible to have a setup where the same encryption key is shared by and usable from multiple smart cards?

I think that T5150 was also not fixed completely.

I found a bug which resulted "Not Found <SCD>" when "SCD KEYINFO" is used with "--data" or "--".
It is fixed in rG54b88ae46062: scd: Fix KEYINFO command with --data option..

Fixed in master. I will backport to 2.2.

I was wrong. Patch is being updated...

Thanks. Fixed in rM7a4fe82a017b: python: Fix key_export*..

So, I'm going to push D513 to both of 1.8 and master (to be 1.9).

I can't see how it occurs. "SCE KEYINFO" and "SCD READKEY" with keygrip both goes exactly same code path (the difference is only the "action" argument).

In T5163#139750, @werner wrote:

You better wipe ecc_d_padded or use xtrymalloc_secure.

Here is a patch:

In future, please try to minimize your log. Your log actually includes information of the session of keytocard before setting key attributes correctly.

I created D513: Support macOS build with SIP by using posix_spawn in tests/random, which is more conservative; It only affects build under macOS.

BTW, I'm not sure if the claim in T5009#136688 is correct.

See also: https://dev.gnupg.org/T5009#136688

See my comment in: https://dev.gnupg.org/T5024#139701

For macOS, with SIP, some program like libgcrypt/tests/random fails, because the hack for DYLD_LIBRARY_PATH by libtool doesn't work for child process:
https://developer.apple.com/library/archive/documentation/Security/Conceptual/System_Integrity_Protection_Guide/RuntimeProtections/RuntimeProtections.html

IIUC, for the build of Homebrew, it is the issue of in: https://github.com/Homebrew/homebrew-core/commit/e7da1e2157b2e8373c3b39ea6398f51588ea537c

Please have a look at T5024: libtool problem for some platforms for 'make check' (program built with -no-install won't work without installation), if make check works after the installation of libgcrypt.

See T2056: libgcrypt: make check fails "random" test on OS X 10.11 with link error, if test with 'random' fails.

ARM64 has been only tested on platforms which support ELF.

Finally, with the physical device, I figure out what's going on.
The error handling in bulk_in in ccid-driver.c is not good for pinpad input.
It doesn't return an error when it is cancelled or timeout (for the user interaction).
And it calls libusb_clear_hald which causes screwed up situation.

Or it might be related issue of name server access like in T3168: dirmngr: gpg: keyserver receive failed: No keyserver available.

As of November 2020, the redirect problem has gone.
And we addressed that as "Legacy GnuPG MiniHOWTO" in rDd51cd2013e66: web: Add warning notes to most HOWTOS..

This must be an issue of SRV record retrieval.
Merging.

Support was added in version 3 card.

Because the original problem of EAFNOSUPPORT has been fixed, I am going to close this bug.

It is likely that EPERM (Operation not permitted) occurs by a system call connect(2) if you have some firewall rule(s) which forbids network access.
The dirmngr use libdns resolver which directly connects name servers.
If this is the case, you can use `--standard-resolver\ to use system's standard DNS resolver instead.

The log file specified in .gnupg/dirmngr.conf is created at the start of dirmngr.
dirmngr is invokded by the first call of gpg, and it keeps running and handle next request from second invocation of gpg.
So, nothing is problem.

On Debian, please see: /usr/share/doc/g++-mingw-w64-i686-win32/README.Debian

IIUC, the error occurred when Kleo is exiting and a destructor (in libKF5ConfigWidgets) is called with null pointer.

Fixed in rDf810f0bc5b13: git.gnupg.org: Update entry page.

For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..