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'm will be using OpenPGP applet for the YubiKey NEO in a virtialized 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)

workaround:
edit gpg.conf and dirmgr.conf manually
rem proxy in dirmgr
insert https keyserver in gpg

With the fix of T4623, this bug is now fixed.

Fixed in master, using Libs.private support.

well, so far it`s win 10 with 3.1.11

The info from your report iis a bit scarce; we would need more to replicate this and also the version of the software and the OS you are running.