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.

@aheinecke as promised, attached some test vectors:

FWIW: These days a thread on Linux is not that costly but nevertheless takes up resources. On other Unices (and WindowsCE) threads have quite some overhead and that was the reason I implemented it the way it was.

I made a clean install of the system and installed gnupg from sources. Now it works strangely.

This has always worked on the client site since we implemented keyserver access.

Omnikey readers only work properly on Windows because the Windows driver uses proprietary extension to make it work. Better don't use them. In case you want to look at details, add

I see no problem to return only revocation packets. Clients must verify them anyway against their public keys and the fingerprint makes this easy. Verification against a primary key delivered along the revocation is more or less useless because that primary key must anyway been looked up in the client's keyring and th local existance of a primary key is anyway required to ask a keyserver for a revocation.

The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys.