I sued the done column because we have not assigned it to any milestone.

Fixed a long time ago.

We can't test this but assume that the fix for T6752 is sufficient here.

With rG239c1fdc28dcd0dc7aa5341be7c966da2231642a we now have a socketdir keyword for gpgconf.ctl. man gpgconf and look for that file. Will be released with 2.4.4.

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

Note that we now have also an option instead of the workaround from 2015

This seemed to be related to T6831 but here we have the case of different keys and not just different subkeys.

I applied your patch and also fixed another possible problem.

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.

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.

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

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.

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.

Appended. Yes, it is considered an invalid signature and ignored. Anyone can insert an invalid signature. The trick here is that during import gpg tracks those invalid signatures and then tries to apply them to other keys. The use case here is this:

Well, the quoted paragraph ended with a

Actually the public key is personalized data as much as a mail address. In any case this is technically required and users take an informed decisions when they distribute their public key to a site not controlled by them.

Assuming 4.1.0 means gpg4win - this version is too old. The user should update and re-open the bug with more details if it persists.

I'd say we should not do anything about this. Stale lock files are a general problem but can be solved using admin tasks. We may provide a tool to cleanup things on request.

Okay, now we have pass the warnings down to gpg and gpgsm so the problem will be easier to analyze. We also stop trying after 10 seconds. Sample error messages:

I don't think that it is a good idea to include the chain. Sometimes certificates are re-issued - they are still valid but signed by another top level cert. The certificate also has the URL from where to fetch the intermediates. Let's close this.

FWIW, when updating the expiration time gpg does this:

That's both not correct. gpg takes the expiration time in seconds since creation time. For a new key this is close to the corrent time but not really. For an prolonging an expiration, this is of course different - the creation time of the key needs to be taken in account. I recall that we once had a discussion and agreed to keep it at time after the creation of the key. This avoids problems with the expiration going negative.

In gpg you may also specify the 4xpiarion date in ISO format. afaic, gpgme supports this.

Searching by keygrip is actually fast with keyboxd.

For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.

Are you using the keyboxd - that is, is this a new installation with gpg 2.4.3 or an old installation w/o keyboxd enabled?

You may better ask on gcrypt-devel at gnupg.org for help.