I learned suspend-to-ram functionality. Currently, for Linux, if we have USB driver in kernel, there are methods to handle suspend-to-ram and resume events. For user space driver by libusb, there is nothing and it should all work well by reseting after resume.

In T3378#106440, @werner wrote:

Can someone please add

disable-check-own-socket

to gpg-agent.conf to test whether this is the cause for the problem. ( note that I asked for this also in T3401)

Sorry for the delay, been a busy busy couple of weeks..

the warning message is probably too cryptic.

Many thanks! This bug is fixed in Gpg4win 3.0.1.

Can you please install the new version and check if the error still persists?

In T3424#106481, @aheinecke wrote:

Noticed one problem already. Google rewrites the PGP/MIME Mails we send into a multipart/mixed mail with the PGP Data as an attachment. I'll see if I can find a workaround :-/

In T3424#106481, @aheinecke wrote:

Noticed one problem already. Google rewrites the PGP/MIME Mails we send into a multipart/mixed mail with the PGP Data as an attachment. I'll see if I can find a workaround :-/

In T3424#106451, @aheinecke wrote:

Already handled the crash in: T3540

I need to get a test setup with google sync. Any chance someone has a test account for me?

I'll try to register myself for the free trial period.

IIRC, I red some hints on using a powershell module to switch the output to binary. I tries to find that mode, or weel its source or scrip) but to no success. It seems to be a common problem with powershell because it is not a real shell as we are used to (where many commands have a /b switch but that switching could also be done using setmode() ).

You're the hero!!!!

Noticed one problem already. Google rewrites the PGP/MIME Mails we send into a multipart/mixed mail with the PGP Data as an attachment. I'll see if I can find a workaround :-/

So I went through the google app sync setup and now have a test account.

I can reproduce the problem.

@aheinecke From a first glimpse, I think we got it. Great work!
I replaced both versions of gpgol.dll as adviced (surprisingly /bin was locked, I expected /bin_64 ).
Thereafter Outlook decrypted all "old" message instantly and without any problems.
Thanks for the effort you spent and the fast reaction time!

Setting this to resolved until we get reports to the contrary.

It was released.

Kleopatra will only expose the values that are settable through gpgconf. Messing with preferred hash algorithms is nothing a user should do as the defaults are thought through and discussed. Mostly such changes come from bad recommendations. So the GUI / gpgconf does not offer this prominently as we don't want to create problems for users.

As GpgEX only queries a UI Server (GPA or Kleopatra) this is a Kleopatra or GPA problem.
With Gpg4win-3.0 Kleopatra got the option "Encrypt with password" in the file encryption dialog, which does symmetric encryption. GPA does not offer this but as Kleopatra is our main UI for GpgEX I think this feature request is done.

The overhead of the start should be reduced by kleopatra as it uses a static c++ object that is only read once. Yes that might contain stale values but we don't expect users to meddle with config files while they have kleopatra open to edit the config.
Similar for GpgOL. Stuff like compliance is only queried once, (maybe twice?) during startup.

Can't reproduce and there were tons of fixes to gpgol in the meantime -> invalid.

Already handled the crash in: T3540

Thanks for the efforts. I will subscribe there to be up to date :-)

Oops I just noticed that this was already reported in T3424 which I somehow overlooked. Let's handle it there as there are more subscribers in that report and it's older.

So both your mails did show the exact same behavior for me. The PGP MESSAGE was shown in the mail and not attempted to decrypt.

Two versions of the same message as shown in the comment of 24th Nov.

I did some experiments with HTML Mails, Leading Text, Trailing Text etc. Everything worked fine for me.

Can someone please add

In T3537#106396, @Xv wrote:

I have some progress and a step back.
Turns out that one of the installed plugins was causing the problem: "PDF Converter 7.1 Outlook Add-in".
I disabled all plugins (except GpgOL) and then enabled them back one by one.
With PDF Converter add-in disabled I'm now able to see the decrypted email body (sent from myself).

Can someone please add

Hi, thanks for the test. This sounds a bit like T3378 if the central component "gpg-agent" hangs everything relying on it may also hang. :-/

We have similar reports in our message board.

I put it at high priority because i want to check / fix this before the next release.

Ok I'm pretty sure that the Google MAPI provider is the problem because it likely has some different Data structures.
For Sender we already have three fallbacks as it's saved differently for Exchange over MAPI, Exchange Active Sync and IMAP. So we probably need another fallback for Google Sync >.<

Thank you, too for the report and testing.

Tested GpgOL 2.0.4-beta6 with Outlook 2010 32bit and Outlook 2013 32bit on Win 10 1709 64bit.

I have some progress and a step back.
Turns out that one of the installed plugins was causing the problem: "PDF Converter 7.1 Outlook Add-in".
I disabled all plugins (except GpgOL) and then enabled them back one by one.
With PDF Converter add-in disabled I'm now able to see the decrypted email body (sent from myself).

I introduce GnuPG to my friend, yesterday. I saw this problem. It's on Windows 7, gpg4win 3.0.1 and enigmail.
Looking through this report, Windows 7 is common factor.

I use the Google Sync plugin to connect with our company Google Apps account. It also synchronizes the calendar entries as well as all other special stuff.
I'm quite sure that the standard POP/IMAP mechanisms in Outlook might not deliver the sender's address (however the receipient's address is contained in the logs above - my googlemail.com address).

I'm using the same Outlook 16.0.0.8625 on Windows 10 with a Gmail Account over IMAP and I have the Google Apps Sync plugin enabled. Everything works fine :-(
What is your senders account? Is that also GMail or something different. In the log I only see that the recipient is GMail.

I'm currently triaging. I give this high priority even if it is testing. We probably need a new GpgOL release soon as there were already some bugs fixed (e.g. Selecting many messages)

Thanks.
So GpgOL can neither figure out the sender's address nor the recpients. It then fails to do crypto because kleo does not know who it should encrypt to.

For now low priority until we receive additional information. From the report now I don't really understand the problem. Maybe T3459 ? as the report mentiones moving mails.

Done. Now Outlook does not crash anymore, but GPGOL emits an error dialog:

Dirmngr should no longer run as a system service. It's now started with user privileges on demand. The

12:33:30/13972/oomhelp.cpp:get_oom_int: Property 'BodyFormat' not found: 0x80040108
12:33:30/13972/oomhelp.cpp:get_oom_string: Property 'HTMLBody' not found: 0x80040108

To keep the tracker clean I'm closing this as a duplicate of T3476 since both problems are very much related. GpgEx would print Internal Error if Kleopatra crashes or behaves unexpectedly.

Here you are

The only way I can think of that this fails if that there are some old files from a gpg4win installation that was not cleanly removed lying around and failing to start.

Strange, do you have any other addons? Maybe some interference.

Indeed the PGP Inline handling should be more robust. If there is leading of following text it should not error out. But as there will always be problems with that I really recommend that you use a standard format (PGP/MIME) to communicate. Then the key would be just an attachment that could be imported in Kleopatra and all the data would be encrypted / signed.

tried to answer in the text with ###:

Normal priority as this should be looked into but is not dramatic.

What Kind of File were you attempting to Verify (e.g. S/MIME or openpgp, detached or embedded). Ideally if it was a public file I could try to reproduce.

Normal priority for now until we get more reports of this. For now we have to assume that while this problem is disastrous it happens rarely as we did not get many reports about this.

Thank you very much for your good and detailed report.

I need to look at the code. I remember that we used to flag executables as GUI applications so that they do not show the console at all.

So the error handling is improved now. We restore the original body on error and show the error in the tooltip of the GpgOL Status Icon.

I can reproduce it if I send and receive with Outlook 2010. I have some working mails in my Outlook 2010 though, this is the reason why I first thought that it did not happen for me. Looking at the same mails in Outlook 2016 works fine.

Thanks for the detailed report. I can't reproduce this behavior. Neither on my Outlook 2010 test system or my Outlook 2016 test system.
I can see several verification errors in the Log. First todo: Communicate the error and restore the original body.

While testing more I find this issue very irritating.

So the selftest fails and then Kleopatra crashes? Mmh I'll try to break my gpg4win installation in a similar manner.