Thank you. All applied and pushed to master.

In 2.4, a user need to specify disable-ccid in scdaemon.conf when scdaemon is built with integrated CCID driver (using libusb) but the user wants to use PC/SC driver instead.

As it is so complicated to check all possibilities:

Searching by keygrip is actually fast with keyboxd.

A workaround seems to be to configure disable-ccid in scdaemon.conf.

Wishlist as the other tasks realted to that are also wishlist and this would be a new feature.

In T6867#179911, @ikloecker wrote:

What if the second signer cannot verify the first signature because they don't have the required public key?

Actually prio is rather low or even Wontfix. Since it has been this way forever and no one really complained. I think deleting secret keys esp. for S/MIME where you can't just create a testing key but need to have it signed by a CA is not really there.

I know I discussed this with werner several times and never really understood it because it makes for an inconsistent user interface / user experience. You delete an OpenPGP Secret key and then the keyfile is gone, you delete an S/MIME secret key and then the keyfile still exists. But it has been so forever T960
Maybe kleopatra should for the very rare cases where a key is used by multiple certificates do a search for the keygrip and warn if this also deletes the secret portion of another secret key? But that would then be also true for OpenPGP.

Ack, I was not sure if we fixed it and forgot to add the commit here.

I haven't looked into it and I think this has really low priority. I'm pretty sure it's a problem with a the out-of-correct-order destruction of (static?) objects on shutdown. If I remember correctly then it is triggered by the DeviceInfoWatcher.

I think this works as intended now with the new certify interface. Also if you grant a key full ownertrust as now is the only option the self certification automatically becomes valid so this then shows as certified.

I did this. da403fe8e4bbc5701ae1d65dd4b0a7267ab43892

Ingo do you know if we have fixed this?

This is still an issue. Since the double click opens a registry entry the working directory of Okular is Windows. Since it is the working directory of the explorer so that is unusable, but it should still be able to somehow take the location from the actually opened file and use that for a save file suggestion.

This works for me

Re-opening to address the missing "Loading certificates ..." overlay.

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.

Didn't you mention in another ticket that the work on this caused Kleopatra no longer to show the "Loading certificates,..." overlay? I still have that issue Kleopatra only shows its window once the keycache is fully loaded. I cannot find the ticket where this was mentioned anymore though.

gpg's output indicates that gpg exits on the first invalid signature. This cannot be changed by Kleopatra. And I think it's irrelevant whether there are valid signatures if one signature is invalid. If you have a contract signed by multiple people then the contract won't be valid because two of three signatures are valid.

If no (OpenPGP) key servers (i.e. set to "none") and no (S/MIME) directory servers are configured then the lookup only allows queries for email addresses. Otherwise, any query with at least one non-whitespace character is allowed.

Yes, It was not my intention that WKD should not work when searching for keys, when keyserver is None. Although such a search could be handled by just entering the email address in the recipient dialog in the file encryption widget to trigger a locate key or in the case of GpgOL to enter the recipient mail but I think that feature is very hidden / not really discoverable for users. And yes an improvement for the search Window in that case would be to then switch to "Enter Email" and use an email validator on the input field for example. So let us handle this as part of T6493

I had a quick look at "Lookup on Server" with regard to doing WKD even if no key servers (neither for OpenPGP nor for S/MIME) are configured. This requires more work because WKD lookup is only possible if an email address is entered while key server lookup also works for arbitrary search terms. The users have to be informed about this restriction which is out of scope of this ticket. I think this fits nicely into T6493.

In T6761#179919, @ebo wrote:

This is not as intended. When doing a search, we wanted No error message and only WKD search should be executed.