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

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.

--quick-addkey is used by one of the modes of gpg_genkey. One option would be to extend gpg_genkey with another mode for --quick-add-adsk. And then using either gpgme_op_createsubkey or gpgme_op_createkey from the existing API by finding a creative way to pass the adskfpr to these functions, e.g. via another context variable. The internal _gpgme_engine_op_genkey can easily be extended to pass the fpr directly.

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

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.

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.

Yes, just a new start function for QuickJob (as in your patch) should do I think.

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.

gpg 2.4 now returns ERROR status lines for failed --quick-add-subkey and --quick-add-adsk.