@dkg thanks for the link.

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.

I was referring to this document:

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 can verify the problem will be solved with 3.1.0, this can be closed.

fixed with rev. 4fbbd134b865b1203b1914eb1623fa65aab8cb75

I might have changed the caller (GpgME++) but what convinced me that the change in core is better is that op_keylist_next sets the return value to NULL on error.

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.

I also stumbled on this problem in the past. However, I did not changed it because I feared to break callers which expect that the passed key object is not changed on error. This may happen in a loop where you test for an ambiguous key and don't save zway the first retrieved key. In the error case (i.e. not ambiguous) this would dump the good key object.

Mr. Heinecke, to make sure, please note that despite the thread title these crashes happened with 3.1.0. beta 38. It would be sad if you do all of the tests and checks with 3.0.3

Apologies for not replying to your mail directly. I've marked it in my INBOX to do the test with 3.0.3 first but have not gotten around to it.

Funny thing, it worked for some time, now it's reproducably crashing again. This might be the better log file.

So, this is tested with 3.1.0 beta 38, reproducable crash

I answered by mail in this fashion:

The severe delay caused by check-trustdb continues to cause problems elsewhere in the ecosystem. It would be great to try to address this so that GnuPG was more responsive for routine tasks like importing a single key.

Thank you for your answer ! :)

You can do a

Fixed with: https://commits.kde.org/libkleo/5b93bddf468b6c067fe062131aee726ed4aa6928

Was reported to me again in the context of paperkey export / print secret key in Kleopatra.

Got it. This was a bug that was around for ages but only started to occur in the verificationresult when we started in 3.0 to show the KeyID / Options for the unknown certificates.