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

With Gpg4win 3.0 we registered associations for S/MIME and OpenPGP Files:

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.

Applied to libassuan master.

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.

Tested it on Windows, with the sleep test patch in Libassuan it does not hang anymore when it hanged without this change.

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

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