I think this might be the same as T4820.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Internally only the long key id is is used thus the fingerprint might give a wrong impression. OTOH, to allow easy migration to future versions, extracting the keyid from the fingerprint is a good idea.

For the split OpenPGP / SMIME it's not intended to only work for BCC, its just the same mechanism I use internally.

I think this is a great feature to have. Thanks for working on it, @aheinecke .

I've just pushed ad55de70930543c1681b11e4bd624be074122b23 onto branch dkg/fix-4855 as a proposed fix, to permit --trusted-key to accept a full 20-byte fingerprint.

The idea of the implementation is that BCC recpients will get a mail with no other recipients. Because Exchange / Outlook handles the sending we can't do it more low level. We use the "Protected-headers" scheme to transfer the original To / CC headers.

In T4513#132777, @Valodim wrote:

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

Thanks for engaging constructively.

Latest one (gnupg 2.2.19)

(I stripped the report down to its core)

Sorry but that really strange.
I need to regenerate those files.
Could you please describe what needs to be done to have proper version?

Do not use arbitary libtool versions or use autoreconf - this is maintainer-only and any problems are not considered a bug.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

In T4513#132770, @aheinecke wrote:

Werner could you maybe at least check for an internet connection, I don't know how to do it on Linux but on Windows it's easy because windows has API for that.

Seems that the public key needed to be exported from the Linux side and imported on the Windows side. Once this was done, the rest of the key information is displayed under Windows for the gpg --card-status.

But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.

and by that bypassing all key source tracking as done by gpg. In any case searching by name or mail address on a keyserver should not be done - at least not by a GUI tool as used by non experienced users.

I agree that this is a tricky problem, but it should really be improved.

The problem is not to check whether there is a connection but on how to decide whether something is a pool or an explictly added single keyserver and how often should we try to connect or read from it. Without marking hosts as dead the auto search features won't work well.

@Valodim probably not so much as dirmngr might behave differently and not mark hosts as dead.

The proper solution is of course to use pkill instead of killall. SCNR.

I can attest to the "growing bit of popular lore": Roughly half the support requests I get to support@keys.openpgp.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".

I can confirm that the problem is gone from a build from the master branch. It indeed retries the search.

Thanks for your info.

I will be using OpenPGP applet for the YubiKey NEO in a virtialized vanilla Debian environment. This emulated card can sign new keys just as correctly. PINs are the default 12345678 for admin and 123456 for user.

Or your card has the key to certify and its fingerprint is: CB522FE0379DDF40A93400D7E4BC91FACDA9A65B

Simply, we need the output of gpg --card-status to identify which key is on your card.

Nope, that's all I had. I'll try to get some debugging info in an hour.

Please show us your card information. Does it have unrelated signing key?

I'm pretty sure. That's the actual output above. Once again, if I remove the smart card, gpg --clearsign starts to just work, without a need to specify --default-key.

Are you sure that you have only one secret key? (run: gpg -K)