Pushed rM7b5182f28893

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.

This ticket can be closed. No further issue with email decryption after applying the provided patch

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.

Could we please merge it to the stable branch (2.2.3 does not have this patch yet) or it is not tested enough? Existing subkey sellection strategy doesn't play well with mail signing and affects GPGTools/GPGMail users as well as any other users with multiple signing subkeys. Thanks!

Moving on, I will just look to make a stand along project for efl-pinentry interface. I withdraw my previous submission. Welcome to resume and move forward with Mike Blumenkrantz version. Thanks!

Frankly, I doubt that this belongs into gpgme.

Andre can you please apply this?

W/o a special tag in the commit there seems to be no way to mark a patch as applied.

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.

Added it. For now it's pretty bare but already an improvement on the old (which only showed "class") and no indication if a signature was revoked.

Prio low, as I noticed that Kleopatra already had some code in there to merge a secret with a public key in a keylisting. This can be used for me.

I pushed this change with the addition of a doc entry and to protect against a not yet initialized socket interface.

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

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