Unconditionally retrying without SRV lookup is not a good idea. SRV record are there for a reason. What we could do is an option to skip SRV record lookups.

In T3056#95172, @wiz wrote:

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

Testing it without patches does not work because:

get-env.c:57:2: error: #error Use of getenv_r not implemented.
 #error Use of getenv_r not implemented.

There are multiple problems. I fixed one Makefile portability issue today.

It's fixed in master.
It is good to backport this to GnuPG 2.2 and GnuPG 1.4.

Applied to master already.

This is applied to master and 2.2.

Thank you for scdamon.log. For the card reader, the interrupt transfer notifies no availability of the card before PC_to_RDR_IccPowerOn.
I fixed this issue in rG0bb7fd0cab2d: scd: Enable card removal check after select_application.. Let's see if it works well for the card reader.

old SRV bug which probably induced code changes for a regression. Its not sure if this is a regression yet or if the router issue is a regression / "feature".

Fixed in 2.2.3 and master. Closing.

Fixed in 2.2.3, too. Closing.

This is the actual error message from your log file:

2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: idVendor: 04E6  idProduct: 5119  bcdDevice: 0525
[...]
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver:   bMaxCCIDBusySlots       1
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID submit transfer (83): 0
2017-11-18 07:45:15 scdaemon[8918] DBG: ccid-driver: CCID: card inactive/removed

The problem is that gpgme-w32spawn.exe uses DETACHED_PROCESS which means that the newly created process does not inherit the console of the parent process.

rO13950a985228 Works around this problem by launching Kleopatra in the background when Outlook is started.
This should both speed up the first operation and work around this issue. In my opinion it's better to waste some resources in the background if Kleo is not needed then to create a bad user experience if encryption does not work and results in a hang of outlook.

Not yet located or identified the bug, but some information.

I could not reproduce it again on Friday. Did some code staring to find the issue but failed. Everything looks Ok.

To compute the key validity (trust) more information may be needed and we can only do that after the changes have been saved. Further, no-auto-chec-trustdb will anyway delay that computation until "gpg --check-trustdb" is run (e.g. by a cron job).

For some reason, scdaemon.log is not yet available here. Please put it again.

Applied to 2.2 branch.

Frankly, I do not understand your problem. We do _not have_ and useful information in the commit logs before December 1 , 2011. You may find some ChangeLog entries in older commit logs but that is from a time when _I_ used a script to copy the ChangeLog entries into the _CVS_ commit logs. That was never done consistently. Thus by looking at the commit log you will get a wrong picture. This is why we need to keep the ChangeLog-2011 files which start right at the top with

This decision suggests that the accessibility of the current source tree
for new contributors (who are more likely to find the static, archaic
changelogs distracting) is unimportant.

You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.

Ok, edited ~/.gnupg/scdaemon.conf to contain

data.gpg is fine and data2.gpg shows this wired behaviour. The difference is at the end of file last two bytes : 0040 vs. 0a40.
Initally i took data.gpg to create the base64 encoded version for the message.

I tried to reproduce this simply by creating an encrypted file with gpgme/test/run-encrypt and then running kleopatra on it "kleopatra /tmp/foo.gpg" kleopatra prints in debug output the decrypt / verify result from GpgMEpp. No error for me.

Shall we close this?