Better to fail loudly instead of silently breaking.

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.

Update: It was my mistake (typical beginners failure): I had to create gpg-agent.conf instead of usig gpg.conf.
Adding disable-check-own-socket resulted in the right behavior, till now:
After some time-out, GpgOL asks for password again and decrypts the content as expected.

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

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)

Suppose a client which connects stopped task of server on Windows. In this situation, if the client blocks on closesocket, that is, some user space work is needed for server side for closing socket of client side, this bug can be explained.

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.

If disable-check-own-socket can stop hanging, D454: assuan_close with nPth could be related.

Mostly done

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

I have created the file "gpg-agent.conf" in the path "C:\Users\<my user>\AppData\Roaming\gnupg\" with the following content:

It's working for me now with that config file as well so far. I'll keep watching too.

I added "disable-check-own-socket" to gpg-agent.conf .
Since 8 hours no "hanging".
I will watch it furthermore...

Could confirm a similar behavior with Windows 7 and Outlook 2010 using GPG4Win 3.0.1.
Time frame for loosing the decryption ability is about one hour or more.
Setting disable-check-own-socket in gpg.conf (didn't find gpg-agent.conf) resulted in "no data" error on all
encrypted e-mails.

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

Fantastic! I have these following issues:

Thanks for the confirmation.

Hi, sorry for coming back so late due to lack of time - but good news is: With GPGol 2.0.4-beta15 decryption now also works for us, great! Now we only have to check for a Outlook 2016 stability issue...

In T3378#106503, @raysatiro wrote:

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

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?

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

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.

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.

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

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

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.

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

Priority Low as it's partly a question and We can't reproduce (for me keygen is reasonably fast)

@PaulJ this sounds like a different problem. For you it does not show. In this report the pinentry open's in the background for file sign / encrypt.

I'm giving this normal priority because I can't reproduce this.

Hi, sorry this is a known issue. To quote the README:

I have installed the update now @JochenSaalfeld and will observe the behaviour over the coming days.
Somehow my Outlook in combination with the plugin messed with the registry. I could only permanently re-enable the plugin after removing all related registry entries in HKEY_CURRENT_USER. Otherwise it would not load on start anymore even if activated by me.

Thanks for the test!

Hello Jochen,

It could depend on the formatting in Outlook (changing hyphens etc.), e.g.
-----BEGIN PGP MESSAGE----- looks sometimes different in Messages.

Great, I'll do it :)

I fixed the problem with multiselection that caused a very similar log for me. The fix is now in 2.0.4-beta6

I'm pretty sure I've fixed it. It would be great if you could try with the latest beta (currently 2.0.4-beta6) from https://files.gpg4win.org/Beta/gpgol/ (just replace your gpgol.dll in the gpg4win/bin or bin_64 folder with the one from there. To confirm that it's fixed.

As I reported this myself and fixed it. -> resolved.

Well the key resolution handling and dialog needs some love. Thats on the todo. But this issue here can be resolved as the op says.

I can reproduce a similar behavior when selecting all mails in a large folder. This was for T3433 It's not a loop it's just a huge load of "Read" events Outlook sends GpgOL and GpgOL looks at every mail.

Thanks. I'll give that a go. The only issue here is that it takes quite a long, random time to happen so chances are a successful fix is one where I never revisit this ticket :-)

The symbols are coming from the message class and are only updated when the mail is viewed and afterwards unselected. It might be that Outlook sometimes does not update the symbol when the message class changes after the message has been read once.

I think I fixed your problem. We had a similar problem in the past and the fix there was not to invalidate the UI (Update GpgOL's status button) so quickly when the selection changed.