Thanks for your testing, it's near. Here is updated patch:

Thanks for config.log of GnuPG. I think that I located the problem; While gpg-agent should be linked to -lpthread, it was not. The configure variable NPTH_LIBS in config.log doesn't have -lpthread. Thus, pthread_* are linked to the ones of stub, and it resulted the error.

Thanks for quick feedback.
Yes, it is a build problem, which should be handled by configure + make.
Could you please upload the build log here, so that I can check it to fix configure.ac+Makefile.am?

ENOSYS means it's linked to stub.
http://nixdoc.net/man-pages/HP-UX/man5/pthread_stubs.5.html
Somehow the build process may be wrong for the gpg-agent executable.

I changed the priority to 'Normal'. The problem now is not the libssh usage, but how we can assume use of secure memory by random generator(s).

By libssh upstream, the problem has been fixed: commit-72f6b34

Here is the function:
https://git.libssh.org/projects/libssh.git/tree/src/dh.c#n227

It would be better not to require gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE). Automatic handling through gcry_control(GCRYCTL_TERM_SECMEM) would be better.

The patch D461 makes gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE) free the allocated secure memory.

It assumes a change of libssh like:

Here is my patch: D461: jent random requires finalizer to deallocate secure memory

@nitroalex Perhaps, creating new ticker is better for this topic.
In the current OpenPGP card specification, there is no way for an application (except having a list of card implementation information) to know wich algo and which curve is supported or not.
So, what an application does is try and error.
I don't like this situation, but I don't know how we can modify the specification.

Thanks again. Good catch.
In Japanese 39 sounds like "Thank You!", that's indeed appropriate to your report. :-)

I changed the title to express the problem.

Thanks for the script.
I confirmed that secring.gpg is not updated when importing key with updated expiration date, by GPG1.
So, for GPG2, it is expired key.

When a command is invoked from Midnight Commander, pseudo tty is used.
You can confirm that by typing tty and see the output of the command after exiting from mc and again typing tty.

I am currently considering improvement of finalizer of libgcrypt, so, this matters.
Looking code, it would be better not to allocate and free the constant,
but use compile time constant data in .text section; Something like: const unsigned char ctr_null[DBRG_CTR_NULL_LEN].

Applied to STABLE-BRANCH-1-4, too.

Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.

Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.

Put the check in configure.

For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.

Workaround is implemented in 2.2.6.

Fixed in 2.2.6.

My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.

Note:
When we change the allocation, hmac256.c will not be standalone any more (as commented in the head of the file), and we will need to change the compile-command line to include libgpg-error.

I check this report again.
The test is single thread, IIUC.

Fixed for forthcoming 2.2.6. Because of T3781: ECC encryption key on-card generation broken.
rG820380335a20: g10: Add "key-attr" command for --card-edit.

I see. Got it.

The patch has two parts; (1) detecting signature by incapable key and (2) limiting key with relevant capability.
I think that (1) is enough. I wonder with (2), (1) would not occur.

Sorry, the patch above is completely wrong, since pk->pubkey_usage is not the right key to check.

If someone claims this is a kind of vulnerability, I think that what we need to fix is signature checking side:

The bug is specific to 2.2, which may select available key on card. When such a selection, checking the PK->REQ_USAGE was missed.

Pushed different version (with teardown-fn).

Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.

I think that I located the bug and fixed. I wonder why Werner put gpg20 tag.

You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.

I realized that KDF support may be incompatible to Gnuk's feature of "admin-less" mode.
I'm going to implement compatible KDF support to Gnuk; That is, KDF data which only has a single salt.
In this case, all KDF calculation (user, reset-code, and admin) is done with the single salt.
With single salt, admin-less mode can work with no problem.

Furthermore, I changed to have an explicit command: key-attr

I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.

It looks like something wrong happened in scdaemon. Could you please try with following? .gnupg/scdaemon.conf

Since I don't have macOS environment and Yubikey 4 (I only have old Yubikey), I hesitated to claim this ticket. But it is me who should take this one.

2.2.6 will have this feature in --card-edit, as kdf-setup. Please test.

For factory-reset, rG2c85e202bc30: scd: Better user interaction for factory-reset. fixed the issue.