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

Alright, I need to weight in with something that may possibly be influencing the failure of the December-01-2017 build to operate correctly over here; since this issue is related to sockets, and I have set up a rather unusual security apparatus on my system ("unusual" as far as computers regularly running GPG are concerned, and that only to my personal experience, meaning no reliable statistics or anything), I think it's worth mentioning that my firewall (Sygate Personal Firewall Pro) is configured to be very restrictive and that virtually anything that utilizes tcp or udp is being routed through socks5 via ProxyCap, and that neither application is currently allowing GPG to have access to any address but localhost (there's a reason for this and has got nothing to do with GPG itself, but that's part of a different discussion).

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

There is request to add support for ssh-certs to gpg-agent: T1756. Right now gpg-agent can only extract the public key from the certificiates and nothing more. The gpg-agent speaks the ssh-agent protocol and as such does not know anything about files uses by ssh to store certificates.

I finally had a crash again today, when I tried to close outlook.
I was running the debug log for several days now, until it finally crashed. Using gpg4win 3.0.1.
Here from the debug file:
*removed entries for privacy reasons*
12:28:46/19196/oomhelp.cpp:remove_category: category 'GpgOL: Verschlüsselte Nachricht' not found.
12:28:46/19196/mail.cpp:parsing_done:882: tracepoint
12:28:46/19196/mail.cpp:parsing_done:885: tracepoint
12:28:46/19196/gpgoladdin.cpp:gpgoladdin_invalidate_ui: Invalidating ribbon: 1D363A70
12:28:46/19196/mail.cpp:parsing_done:900: tracepoint
12:28:46/18768/parsecontroller.cpp:~ParseController
12:28:46/18768/mimedataprovider.cpp:~MimeDataProvider
12:28:46/18768/attachment.cpp:~Attachment
12:28:46/18768/mimedataprovider.cpp:~MimeDataProvider
***here I closed Outlook, but Outlook froze. I then killed the process in Windows.
12:34:02/19196/windowmessages.cpp:gpgol_hook: WM_CLOSE windowmessage for explorer. Closing all mails.
12:34:02/19196/mail.cpp:close_all_mails:1084: tracepoint
12:34:02/19196/returned from invoke

It's in gniibe/scd-kdf-support.
I think it's good to add to GnupG 2.2 branch.

Not sure this should remain open. Months later a release was done excluding this. Originally mentioned on list in October 2016. Over a year later still not included. Very discouraging. I guess I can just see about having this external for myself. Shocking that FLTK and QTK see more usage than EFL which is part of Tizen OS. Clearly issues with either me, or EFL. Some reason it was excluded and being ignored. Seems nothing I can do either way. Oh well, I did all I could for months. On a very small contribution...

I could have sworn a patch/pr was merged into repo or something. It seems it was not. Guess I must be mistaking it for some other contribution. Guess I will give up on trying to get EFL into next pinentry release. Which may take another year or so. Despite the fact I have been using it daily for many months now. Oh well.

I've tested the fix and so far I found no problems with decryption and email rendering.
If you want I can report back here, after using GgpOL several more days testing the fix in day-to-day usage, and then if everything is fine we can close this ticket.
Thank you very much for your time.

Why without it was already committed to repo? Is there some problem I
am not aware of?

Released. Unfortunately without EFL but we need to have a release after more than a year.

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

:-(

Ok here's an update.

Superb! Testing gnupg-2.2.3_171201.exe as I type, and it's already working past the time it would normally cease to respond :)

The registry key does not exist on my system, and neither does the c:\program files (x86)\GnuPG\bin directory. There is only the Share directory under c:\program files (x86)\GnuPG\

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.

A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.

A new installer with an updated libassuan is now available. To download gnupg-2.2.3_171201.exe please go to https://gnupg.org/download/ . If you had the disable-check-own-socket in your gpg-agent.conf, please remove it so that we can really see whether that version fixes the problem.

The error is fixed with "disable-check-own-socket"
If someone is interested for next times, the log-file "gpg-agent.log" is on the path "C:\Users\<my user>\AppData\Local\VirtualStore\Program Files (x86)\Mozilla Thunderbird\".

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

Adding Windows again because on Unix it is unlikley that our close will block. A documented blocking behavior is only defined for STREAMS

Yeah, that looks correct. Good catch. The bug exhibits itself when gpg-agent checks its own socket. In this case gpg-agent is both, client and server, and due to our userland multi-threading we get blocked. The suspend/resume things makes the deadlock more likely. Note that we have the same problem on Unix.

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.

After a week with the current version, including a registry cleanup, I had no crashes in Outlook. At the moment it seems to be running stable.

Applied.

To sum up: Outlook can't decrypt a reply, although it can decrypt a direct email from the same sender.
Another thing I just noticed: once Outlook receives the reply (the one it can't decrypt), I can no longer move emails to other folders. If I deactivate GpgOL plugin, I can move the messages again.
Can I pm you the saved message ?

Thanks everyone. I think that the problem is identified and fixed in libassuan.

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

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.