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)

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.

Fixed in master.

Yeah, this can be done.

I already tried reinstalling gpg4win without first uninstalling it (I thought it might repair corrupt files) but now I uninstalled first and it is working again.

I searched through C: and D: and found it in D:\Programme\GnuPG\bin and in D:\Programme\Gpg4win\bin - both seem to be created by gpg4win. I'll try reinstalling, hopefully without deleting my private keys...

The DLL libassuan-0.dll was not found or the system somehow found.
Do you have other versions of GnuPG or Gpg4win installed? Please search the system for copies of the above mentioned DLL?

Fixed in master and 2.2

Really interesting: The code didn't changed since since 2003 and the bug must have been there all the time. It does happen only for 25% of the certificates with CR and LF; the others have padding characters at the end '=' which is also an indication of the end of the base64 block. I wonder why this has not been reported more often; maybe because most people import binary certificates.

Wald certificate will be fixed very soon. But as it is not fixed yet, I provided an http link, not https for you.