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.

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

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.

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

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.

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

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.

Forgot to mention this bug in the commit addressing this. ( 278893850ed926d4646929ee97576a8d09fd4998 )

You may have other changes on your system as well.

Should avoid the problem. Then import or create n OpenPGp key first and the next time you should(tm) not be bnotered by the bug.

Okay, I took your suggestion but also improved the documentation. Fixed in 2.2

Thanks for your reports.
I can finally reproduce this on a new Test VM which I gave little resources. Most of the time it does not work. Sometimes it works. Looks like a timing issue, on my main development VM which is fairly quick it always works. I'll work on it.

Oh that is not good. A passed arg should not be closed by the called fucntion unless that fucntion is documented as gaining ownership of it. Let me check.

Sorry for the confusion. We tried to reduce the interactions necessary to encrypt a file and our rationale was that users mostly want to either always use textmode or never. (Also See T3486 )

Thanks for your feedback. But this is intentional. There were two problems with with this:

Thank you Werner. Do you know when the next release will be? Is there a way for me to temporarily fix the current version in the code?

But this does not explain why it works on the same system with GPG 2.1.11 instead of 2.2.2.
Here is what happens after applying the suggested quick fixes:

--- ~ » sudo pcscd
--- ~ » sudo chown enno /dev/bus/usb/002/005                        1 ↵
--- ~ » sudo chgrp users /dev/bus/usb/002/005                      2 ↵
--- ~ » ls -l /dev/bus/usb/002/005
crw-rw-r-- 1 enno users 189, 132 16 nov.  15:17 /dev/bus/usb/002/005
--- ~ » gpg --card-status
gpg: selecting openpgp failed: Aucun périphérique de ce type
gpg: la carte OpenPGP n'est pas disponible : Aucun périphérique de ce type

So you either need to start pcscd or you fix the permission of the device so that GnuPG's scdaemon can access the card reader using its internal access method. There are probably some udev rules which need to be adjusted. For a quick check you can manually change the owner or group to your own user or one of your groups. Then it should work again.

Dear Werner,

Entering on the shell

lsusb | grep USB

This is verly likely be fixed with commit 5ecef193bc2144e6d51a6bd5727bfd08a0d28b66 which will be released with the next gpg4win version.

Add the tag of npth (forgotten).

Done for libassuan

This has been fixed a while ago my having dirmngr print a hint on the possible problem. gpg will then print a warning about a problem with the Tor configuration and with --verbose print the hint on solving this as well.

I am connected via IMAP. Sometimes Outlook also crashes when I handle a message that is in a local inbox not directly associated with an account. It may be relevant that I have two IMAP accounts configured that run on different key pairs and all messages are shifted to a local inbox on arrival.

This was only for multipart/alternative HTML mails which was a fairly recent feature for GpgOL.
The encoding for html mails was handled incorrectly as it took the encoding of the text/plain part and not the text/html part. Fixed now.

Indeed. Thanks for your report I can reproduce this. Funny how this was missed through all the Beta's and pre release testing.

How are you connected to your server? I mean IMAP, or Exchange MAPI or is it a Hotmai / Outlook.com account?

Outlook 2007 is deprecated and we will only fix security issues there (or remove it altogether in the future as Outlook 2007 is no longer maintained by MS). GpgOL for Outlook 2010 and Later in Gpg4win 3 has HTML Mail support.

FWIW, I added a gpgtar.1

Pushed to 2.2

You could use the --directory option. However< I agree that your suggested changes is less surprising then the current behaviour. Thus I would consider this a bug fix. Can you please apply to 2.2?

That does not look like a GnuPG or GPGME bug but more like an incompatibility in python-gnupg. Please report this to the maintainers of python-gnupg. I would have suggested to use the GPGME Python bindings but unfortunately we don't have a Windows version on them yet.

I prefer plain git patches. Thanks.

That should be emitted only in verbose mode. I have verbose almost always enabled so I didn't caught it. Thanks.

I created a Differential request for this change; not sure which you prefer.

I am building on a CentOS system that comes with gnupg 2.0 and I'm trying to make an isolated test install of 2.2. It would probably work fine with the right PATH, but I thought the --with-*-pgm options might help assure the new install was used.

Multiple bugs fixed here:

Tested with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 10 (64bit) with Outlook 2016.

The Documentation is installed. You can find it under Help -> Gpg4win Compendium in Kleopatras menu.

I enabled the error and did the following with Gpg4win-3.0.0-beta17 with GpgOL-2.0.2-beta8 on Windows 7 (64bit) with Outlook 2010

In T3442#105339, @aheinecke wrote:

In T3442#104402, @JochenSaalfeld wrote:

1. Mails encrypted with S/MIME are stored with "No Data" in the sent EMail folder, but arrive properly at the recipients (you will recieve a readable copy, if you add yourself to the list of recipients). This Issue breaks the GpgOL Plugin after some time which is leading to the described Problem.

Fixed with 474cc15d8e331c9def298dbbfe3b99e6c8cf8035

What is your use case for these configure option?

@tstreibl thanks for helping with your feedback!
Please note that this issue (T3442) still has the status "testing", because we want to perform some more tests before declaring it resolved. :)

In T3442#105466, @tstreibl wrote:

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

Sorry for my inpatience...but it's a little bit hard to understand why the above, very simple test procedure obviously isn't reproducible on your systems.

Starting Outlook still bring up the "Fehler in der Benutzeroberfläche von XML von "GpgOL .....Unbekannte Office.Steuerelemente-ID: TabComposerTool" Message Box.

tested your new .dll. Created a new email. Choosed "sign". Pasted an email adress from outlook address book into the "an" field. Outlook crashs. Took me 2 seconds to test. What the hell are you testing?

Thank you very much. Both the signed only and the encrypted mail are fully valid for me (checked on the IMAP server and with kmail) and don't contain any references to gpgolXXX.dat. This means they were correctly converted to valid PGP/MIME Mails.

Dear Andre

Thanks for the report. This is indeed badly broken. I'll work on this now.
I can reproduce and also have a reproducable crash when trying to encrypt a special folder. This must be a recent regression because I tested this some months ago and it worked fine.

This might be a reason that we got multiple reports for Kleopatra since 3.0 was released that it hangs on keylisting: https://bugs.kde.org/show_bug.cgi?id=381910

Everything works correctly but the warning message is probably too cryptic. It means that the signature could not be checked because the public key that created this signature is not found. It needs to downloaded, imported and verified. (See: https://www.gpg4win.org/package-integrity.html )
We improved the warning message with gpg4win-3.0

This means that the MAPI to MIME conversion did not happen.

Jochen could you please test this on one of our test VM's again and resolve this then?

A new binary for GpgOL can be found under: http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8/ or for http://files.gpg4win.org/Beta/gpgol/2.0.2-beta8_x64/

Nagi: The third suggestion (adding "--pinentry-mode loopback" to your command) should work in that case.

@aheinecke Regarding closing: I'd say that we should have a test on this one and then close it for only the refocussed "send-folder problem".
Can you provide an updated gpgol.dll drop in replacement?
Some of the users in the forum may be willing to test as well.

I think this is resolved here. As we now have the check in the installer to warn on Vista and disable Kleo / pinentry-qt