Observation: When downloading a new version of Firefox, there is another dialog before the UAC comes and the following UAC is fine then. Question: Why does Gpg4win3.exe directly goes to the UAC and firefox.exe triggers a different dialog?

So I can reproduce the problem on a Windows 7 virtual machine with all important updates up to the 5th of February, 2018.

Thank you for the test :-/
So back to the drawing board.

Version 2.0.7-beta6
Test 1 (without S/MIME support):
encrypted e-mail shown as plain text (-----BEGIN PGP MESSAGE----- ...), can be decrypted via clipboard and GPA.
Sent message shows same plain text as received one.
No encryption icon in Outlook Inbox.

The changes are made as described. Could you please try:

Trying to reproduce this / staring down the log, I think I might have found the problem.

This is the log output for sending a GPG message to myself:

So I tried this on Outlook 2016 MSO (16.0.4639.1000) 32-Bit

Does this happen to you for all mails or just some? From the GpgOLXXX.dat I can't see anything wrong.
My expectation is that something goes wrong when updating the plain text into the message viewer. Again, could you please attach the GpgOL Debug output? That might help.

Steps 1. and 2. are now implemented in the async-enc branch of GpgOL. The keyresolver patches are updated for me and partially commited.

Ah under Linux we ran into an assert which made finding the problem easy. The bug was introduced by the fix for T3602. Will be fixed in the next release. Apologies for the inconvenience.

Thanks for your report. I tried this several times. Could not reproduce it at first but I could get it to crash sometimes. Even without GpgEX just by double clicking the signature file.

1. Collect all data in OOM, then start a thread to do the encryption.
2. Do a proof of concept that this actually works and outlook lets us do it with our usual window message async handling.
3. Update my Keyresolver patches in Libkleo and build a "libkleo-tool" to do the key resolving.
4. Figure out Window Management / Create a Qt Overlay over the Mail window to block it from closing while encryption happens. This will resolve all bugs related to window mangement of the current key resolution.

From your log I can see that the verification fails with "Unsupported Protocol" which is weird in itself. But at least with the fixes for T3538 (they are included already in your version) it should then show the unverified body. So this is a second problem. I tried to reproduce this for sent mails but even if deliberately break them they are displayed correctly.

Hi Andre, thanks for your help.

Damn I thought we had all these kinds of display issues fixed now with 3.0.3. Is this really GpgOL 2.0.6? (you can take a look at the option dialog of gpgol to confirm this)

In T3739#109615, @aheinecke wrote:

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters.

BTW, using a long passphrase for public key encryption is in almost all cases useless. The passphrase is there to protect the private key, the passphrase is never sent to another site and will only be seen by gpg-agent, pinentry and the tty I/O software of the OS.

FWIW, Running gpg from the commandline with option -v shows the pinentry flavor.

The fix was released with Gpg4win-3.0.3

The default Pinentry for Windows is pinentry-qt it should both be accessible with descriptions and screenreader API support and it should allow you to paste in passphrases. The passphrase length is limited at 255 characters. This limitation comes from GnuPG and is there both for Windows and Linux. Have you tested Pinentry-qt with a screenreader?

Gpg4win-3.0.3 has been released.

No more reports of this since 3.0.2. With 3.0.3 I fixed an additional memleak which should further improve this. Resolved for now.

For the 3.0.3 I tested more with Microsoft Exchange Online, an Exchange 2012 Server and could not reproduce such problems. So I'm lowering the priority to normal as I don't think many users are affected.

Multiple confirmations -> Resolved.

I can also confirm that 2.0.6-beta9 fixes my issue with this too. Also with my own exchange server!

I can confirm that this appears to be fixed in 2.0.6-beta9.

We now have update handling in the installer and this is the first thing the update handling fixes.

I understand now that README's for other languages are installed as aliases and added some missing ones.

I've changed the behavior now so that PGP/Inline also works with Exchange Online.

@hs could you please retest with 2.0.6-beta8 http://files.gpg4win.org/Beta/gpgol/ and attach the log file again.

Implemented with: https://commits.kde.org/kleopatra/9d1ebcb1e5f6b44a745c7e947f2e8eaf88fff786

I can confirm that PGP/MIME works ok for me.

Indeed, thanks for the note. I added the variable only later on for the check of protocol unknown and overlooked to update the setProtocol call.
I've updated the code accordingly.

All e-mails I tried to open with 2.0.6-beta7 gpgol.dll were readable and showed the correct content in my environment, now. Great!

@aheinecke thanks for the fix. But I have a suggestion for the code(I only looked at the diff):

Fixed with https://commits.kde.org/kleopatra/066c6e4ca82d064437f1902838d09fa903147e40

While trying to reproduce another bug I've set up an account with Exchange Online. With that account I had similar behavior with empty mails shown. The behavior also matched to the logging of the last mail in your log.

You might want to look at: https://wiki.gnupg.org/TroubleShooting#Passphrase_on_the_command_line

Can you please run debugview ( https://technet.microsoft.com/en-us/sysinternals/debugview.aspx ) and attach or paste any lines here that start with "org.kde.pim" when you try to encrypt the folder?

Thank you for your report. I can reproduce this problem. Kleopatra correctly looks for the signature file but then fails to set the protocol. This results in an internal error.

Ignore my previous comment - seems that if I'm off our corporate network, I have the issue. Back on the network, Kleopatra is ok, and the gpg command completes. (I suspect that there is a firewall rule required, as the firewall is only enabled off network.)

Tried that, and it complained that the gpg-agent was not running. Now Kleopatra fails to , constantly trying to load certificate cache. Self test fails on UiServer Connectivity. Was fine up to that point.

I guess that the MDC indicated a broken encryption or no MDC was used at all. Can you pleae run the decryption of the file on the commandline? Assuming that thar the file is msg.eml you do:

By the given version number, do you mean: with gpg4win 3.0.1 it worked with 3.0.2 id does not work anymore?

Please explain en detail what you are trying to do and what the error is. Thanks.

If you are encountering the problem, please

1. Check that you have updated your Windows operation system to the latest version and you've got all security updates. (As some necessary certificates may have come later with an update.)
2. Does the behaviour change if you "investigate the certificate chain" through -> Properties -> Digital Signatures?

We recieved another mail by a customer about this issue today: