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.

Tested on Windows with Kleopatra and 2.2 and with gpgme and 2.4 on Unix.

Okay, I known do the same what we do for a single root certificate, that is mark it as "not trusted" ('n').

We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.

That is a feature. Consider the case that ~/.gnupg is on network file system and thus possible in use on several boxes. Thus before we remove stale lock files we do not only compare the PID but also the hostname. Granted, this is rare but we have had such cases in the past with locks.

See also T6465

We always try to update the stub files because meta data of the key material might have changed due to the use on another box. On Windows the file system watch might be triggered by the remove of a key file right before writing it (cf. the usual Windows rename file problem) which is the cause for the loop. The new patches now detect whether a key file actually changed and avoid writing it back to disk.