Which libgcrypt version are you using (gpg --version shows it)

I see hundreds of lines output but can't easily detect what you question or bug is. Please strip your report down to something we can triage more easy. Also what OS etc. Thanks.

T2854 is a duplicate of this but contains more up to date information. So I'm closing this issue.

Does this still happen with gpg4win-3.0.2?

Gpg4win 3.0.2 is released which contains even more fixes for GpgOL -> Resolving this. Please let us know if you still have Problems that are not tracked here.

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

This works now. There is a problem still if the agent is not running with the default homedir or under other users. But this is handled in T2146

@werner This is sometimes still an issue. E.g. if the agent is started with a different homedir. Is it ok to just use TerminateProcess on any gpg-agent?

I'm changing this issue to resolved as I opened T3601 and T3602 for the problems mentioned in this issue. As it is better to have them separated.

I thought about (2) when implementing the new "decrypt" action in Kleopatra but we did not give it high priority as we were unsure if this is a real world problem.

sadly this happens with nearly every release that some Anti Virus software reports false positives ( https://wiki.gnupg.org/Gpg4win/AntiVirusSoftware )

Do you mean, GnuPG fails for a particular message, while it works for other messages?
Or do you mean, GnuPG fails for messages from a particular sender, while it works for messages from other senders?

The new reader arrived. Works find for every message - except obviously this one sender.
See reader https://pcsclite.alioth.debian.org/ccid/supported.html#0x04E60x5116 ti should support large APDU. Same error messages
I think we are on the wrong error track here. It is not the reader. I now tested 4.

There is now also Gpg4win-3.0.2 with that gnupg version available.

I've been running gnupg-w32-2.2.3_20171207.exe for about as long as it's been available and no hanging whatsoever. Thanks a lot!

Thank you for your cooperation.

I still have trouble beliving it is the reader. Since I tried now 3.
As well I have a 4096 bit key and everybody has been encrypting this with my key. Therefore it does not make sense to me.

All commited. I created a new installer gnupg-w32-2.2.3_20171207.exe which comes with the new libassuan 2.5.1 and the two required patches for gnupg.

Fixed at last.

I looked into it. The problem is that attachments are opened as "Read Only" so we can't change the message class or handle it ourself. Once opened there is no apparent way to change the message to read only. Only if the message containing the attachment is marked as modifyable:

I tried to reproduce this with current GpgOL and it just worked. Even if I connected Enigmail to Exchange (Outlook.com).

For Gemalto USB Shell Token V2, libccid has known issue: https://ludovicrousseau.blogspot.jp/2017/03/gemalto-idbridge-k30-k50-ct30-and-zero.html
I don't know about ACR 38U.

I experience this same behavior, standard shell. Both with admin, windows live based account and local, non-admin account.

Here two other Reader example - same message - same problem:
Reader: Gemalto USB Shell Token V2 (00483E73) 00 00
Reader: ACS ACR 38U-CCID 00 00

I just tested with intevation's CA on Windows and it works. It also worked with our test.ca in the base test before the 3.0.1 release. I think this is resolved.

We now check for an error of the gnupg-w32 installation (which should not happen normally) and show a Message Box on error.

It's also fixed. There was a problem with the error handing. A canceled pinentry is communicated as an error with code operation canceled.

In T3577#107074, @aheinecke wrote:

So if the user had a "real" error it might have crashed instead of showing the error.

As a note: The second crash might be related in that the crash could happen on any error. So if the user had a "real" error it might have crashed instead of showing the error.

Indeed easily reproducible issue.

Thanks for testing.
I created another patch which can be applied independently: D457: Avoid crash using nPth

Looks good. With the libassuan-hang-test.diff and D455 D456 applied on current master branches it no longer hangs. It hung with only the libassuan-hang-test.diff.

The patch above libassuan-hang-test.diff requires D455 and D456 applied.
I guess that without the patch for testing, current gpg-agent would just work fine, possibly. (no crash)

For better reproducibility of hang, this is more better:

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

If you can get the developers to make a try-build that is built securely then I'd guess most of us would be happy to try it. Not all of us have a build system for gpg.

To reproduce this problem of nonce write->read race on Windows, and forgotten wrapping of read/write, please apply this patch for testing:

For Gemalto Shell Tokens: http://support.gemalto.com/index.php?id=tokens
There are three variants. Please describe detail.

I checked a card reader: https://pcsclite.alioth.debian.org/ccid/readers/CardMan3121.txt

We had similar report back in 2015, but it was not fixed in GnuPG (possibly, card reader problem):
https://lists.gnupg.org/pipermail/gnupg-users/2015-September/thread.html#54345

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

:-(

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\

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.

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.

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

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.

I am using an Antergos Linux (Arch Linux).

Please do not paste such long debug messages - they are not helpful. Please try to explain the error. From what I can see from that long dump the DNS server failed.

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.

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.

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

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

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.

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 :-/

Fantastic! I have these following issues: