I'm doing the test. I'm currently waiting on a hang with the test change applied.

Indeed. Since Gpg4win-3.0 Gpg4win uses the "official" GnuPG-w32 installer. This installer is bundled with Gpg4win and extracted during installation into the temporary directory and executed from there. So your problem is likely that GnuPG is not installed. As GnuPG is the core component of Gpg4win this will lead to a broken setup (although the error should be detected so I'll leave this issue open for that problem.

Hi,
this is intended behavior. KLEOPATRA_LOGDIR is a development / testing setting and it can be useful to look into which data is sent to GnuPG.
Please disable Kleopatra logging as described in:
https://www.gpg4win.org/doc/en/gpg4win-compendium_29.html

@patoberli This looks very much like a crash I also observed on close and fixed with 1d0660fa53d357247ac84545f9259244a1d9400c the crash has nothing to do with the hang but thanks for the feedback anyway.

We now read the headers as a stream. This fixes the detection of the content type for your example mail. It now correctly fails for me with "No Secret Key".

Received a test message and I understand it now. The header lines in the test mail are so large that they cannot be queried as a single property (out of memory because the max is pretty low, 4k or so) but have to be accessed through a stream interface. Many of the headers relate to Thread and In Reply To etc. so this explains why the problem only happens on reply.
I think I can quickly fix it.

Many improvements since dec 2016 to gpgol. Latest master is much more stable (needs a Gpg4win release)

Last commit of the series: https://commits.kde.org/kleopatra/c5567d6915bb0e76284281590282d942966322b0

Implemented with https://commits.kde.org/kleopatra/3ddc062f72853738904d1e25dd2d4440e348fd43

Yes please you can send it directly to mailto://aheinecke@intevation.de
If you want to encrypt it my key is 94A5C9A03C2FE5CA3B095D8E1FDF723CF462B6B1

I am very happy to hear that! Thanks.

Added with https://commits.kde.org/kleopatra/2b22bccfa852cd22e62d95c2270187c7f23b63cf

For now I've added messages to make it clear to the user that most actions won't work with G Sync.
Better to fail loudly instead of silently breaking.

Implemented with https://commits.kde.org/kleopatra/805f5cfafe9f464de6f6a22619a74062ae781bfd

Indeed, this was lost by switching to the new dialog. Fixed with: https://commits.kde.org/kleopatra/005a28149fcb7f318676de47aee3014fc83b3f78

I can no longer reproduce this. We had another report about this were we also tested this and it's ok with recent GpgOL 2.x versions. -> Resolved

Fixed with https://cgit.kde.org/kleopatra.git/commit/?id=59ebe7da257131757f98e77912e39b3fd14ae3af Kleopatra was too agressive in the dialogs and always tried to stay on top. This makes sense for the Certificate selection dialog in GpgOL but not for the file dialog.

Nevermind. The keylist can be accessed by activating the line action (clicking on the button)

Does not happen for current GpgOL versions and OL < 2010 support in GpgOL is no longer maintained -> resolved

Fixed / Workarounded with https://commits.kde.org/kleopatra/9bef188fd2a2b820a63e9c7ed130c0990b7f3ce5
I was unable to reproduce this on Linux so no Valgrind / GDB. Fix is not pretty but works and ultimately we want to replace that dialog anyway.

Mostly done

Problem was indeed that QFile::Rename does not work across partitions.

It would be very helpful if you could export ("Save As") such a mail in Outlook and attach it here / send it to me. I don't have to be able to decrypt it but I would probably be able to figure out why it's not detected as a crypto mail.

As the crash is fixed and awaits release I think this issue is resolved. But that does not mean that we support G Suite sync. I don't see a quick fix :-/

Priority High as we should decide for the next release in which direction we should move.

Thanks for the confirmation.

I tried a bit to find a Workaround. As far as I can tell Outlooks built in S/MIME Support does not even work with GSync. If anyone can send S/MIME encrypted or validly signed mails trough GSync please let me know.

In T3378#106503, @raysatiro wrote:

I assume it goes in %APPDATA%\gnupg\gpg-agent.conf.

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.

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

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.

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

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).

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.

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.

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.

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.

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.