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.

Confirmed with two other cards. in the gpg-agent log I also see MARKTRUSTED not supported lines while the card is inserted - this is cause by the loop in Kleo.

This is a generic parent task and does not require workboards for specific branches.

FWIW, the Fileversion is actually the Git revision in decimal

You can't decrypt using the Esign application on such a card. Please provide more information off-tracker.

Testing in 2.4 will not be easy because it requires code modification just for testing. However, de-vs is not supported by 2.4 and the greater plan is to get 2.6 approved for de-vs.

I'd prefer to not use the spawn helper at all. All currrent Windows versions allow to decide which handles are to be inherited and thus there is no more need for the helper.

@gniibe: This is a pretty old bug; given all the changes of the last year, should we close it now?