Note for myself: This is the behavior for key resolving in GpgOL. GpgEX has different code for this and the above examples will not work.
In GpgEX the group is not resolved into its component keys currently.

Done. I have verified with the test runner run-verifyopaquejob that verification still works and that the warning is gone.

I would use ALGO of gpgme_createsubkey to pass the fingerprint of the ADSK. This can be justified because the algorithm is an implict property of the fingerprint. Obviously we also nee a new flag to do switch to this behaviour. A new GPGME_CREATE_ADSK comes to mind.

I fully agree.

Finally officially tested with Gpg4win-4.2.0 and a Yubikey 5 NFC. Works for both OpenPGP and PIV.

Tested with Gpg4win-4.2.0 and a Yubikey 5 NFC.
CSRs are generated for both available keytypes rsa2048 and nistp256.

In T6880#180682, @TobiasFella wrote:

In the C++/Qt parts:
I think we then don't really *need* anything, since we can just set the fingerprint in the context for the job, but it would make sense to introduce a function that wraps this into a nice API.

My concept would be to:

• add a GENKEY_EXTRAFLAG_ADDADSK for _gpgme_engine_op_genkey and gpg_genkey (or do that more implicitely, e.g., by detecting !USERID && KEY && PUBKEY) and pass the subkey fingerprint in pubkey
• use gpgme_op_createsubkey; pass the adsk fingerprint in a new variable in context

For the similar task to add an existing subkey to a key we have GpgAddExistingSubkeyEditInteractor. This uses the much more complicated gpg --edit-key interface. Maybe we want to avoid this.

Thank you for the bug report. Although it's a corner case, it is a discrepancy in the implementation which results unrecoverable situation of the device.

Fix for i386 assembly pushed to master and 1.10 branch.

Before adding code please first come up with a description of the planned API extension.

I don't think that it is a good idea to have such a specialized API for this task. What we do here is very similar to adding a subkey and as such the APIs should be merged.

May be a still running daemon from another version or a a problem during the first install.

Just a quick first comment: We usually commit core changes and cpp/qt/etc. changes separately. So please split this commit before merging it to master.

That was my fault in commit rG8fc9de8d6bf663f7c8419b42dab01f590a694d59 obviously I assumed that the macros were always used.

I see the reason.