Ah man. So let me ask you for clarification in case I am not understanding this right. You're saying I encrypted the message with someone else's public key?

I could somewhat reproduce this problem when I disconnected the connection to Exchange from my Outlook and then tried to respond to an exchange mail. Although for me Outlook did not Hang and an error message (with a General Error) showed up.

• fresh install of Gpg4Win 3.0.2
• reboot
• openening Outlook 2010 with only one plugin (GpgOL)
• sending an encrypted email to myself
• trying to open that email (no content)

1. exit gnupg software;
2. ctrl+shift+esc: end the process that starts with the 'GnuPG's ...' character~；
3. windows + r : %appdata%, delete ‘gnupg’ directory；

Thanks for the report and the log.
I see the problem. In your case of a reply outlook does not give us the SMTP address for the recipient but an Exchange DN

@aheinecke Because it was mentioned in another comment, I've tried to restart Outlook with the GpgOl plugin enabled, only. Same result. But the fact that I could see the message just after arrival, but not in a second approach may point in a direction that incoming messages are processed by an server-based filter changing potentially vulnerable email content (as embedded links).
I could try to log the complete process of sending an email to myself, decrypting once and failing in a second trail. This would actually increase the size of the log file.

@hs Your log is interesting but I don't yet understand it. We see a "Load" event for an encrypted mail, create our internal data modelling. But later there is a mismatch between the reference Outlook gives us and our internal reference (Failed to find mail in map).
Out of the blue there might be something I could do in that case but it's still somewhat unclear to me why this state occurs.

Looking an example code of http://g10code.com/docs/openpgp-card-v21-free-source.zip (Note that this is just an example code), 6A88 can be occurred for PSO:DECIPHER when:

Well, I meant to do this on the command line (cmd.exe). Replace INFILE with the name of the encrypted file and OUTFILE is the name of the file which will receive the decrypted data. You can't do that in the clipboard.

I included two pictures of what is going on. The first picture is what I get from trying to decrypt the line that you gave me. The second picture is the original issue I was having. I do appreciate your help

It all depends on your system. This is why this is an _option_.

Can you please try to decrypt this message on the command line:

I also have had this problem. I just opened up my laptop for the first time in years. I was trying to decrypt text I encrypted years ago but I get that same error stated in the original post. Now I just remind you, this was encrypted years ago. In the encrypted message, after it says "begin pgp message," it says "version: GnuPg v2.0.20 (MingW32)" i am not sure if that matters, but that is all i have to give on my end other than i am currently using gpa 0.9.10 GnuPG 2.2.3

Perhaps as a last word on this it may be reasonable to remove that strange "--enable-hmac-binary-check" as it does cause problems.

Just installed Gpg4Win 3.0.2.
Had a very similar effect with Windows 7 / Outlook 2010:

• Sending an encrypted e-mail to myself.
• E-mail will be decypted once after receiving.
• After that, e-mail is shown as "unsecure" and with empty message body (both in preview and own window).
• E-mail in "Sent" folder still decryptable with right content.

I've added gpgol.log for opening Outlook again after receiving the e-mail (with empy body, now).

Please reopen or comment if that problem still happens if you move away the gnupg home directory.

Case Insensitive Sorting is fixed with:
https://commits.kde.org/kleopatra/856aad228a81f542f821209ae2c796d9b7160263

Great, many thanks.

no i have not any software that interfieres.

Strange, do you have any unusual Group Policies or some "Security Software" that might interfere with the running of GPA / Kleopatra (they open a local socket).

The fatal bug you reported can happen if the process is running out of secure memory. In general it should return an error but there is one place where we assumed the allocation would always succeed. This has meanwhile changed in the repo and will go into 1.8.2 However, this is not the real problem you have but just a wrong error behaviour.

I can reproduce that problem and have opened T3614 for this.

Hi, first of all I want to report back that with beta15 that the following issues did NOT arise anymore, fantastic!

Please open another report, not reusing similar. I don't think it's same bug.
Please note that GnuPG's ssh is not fast enough (intentionally), its rate is usually ten connections per second.

I'm seeing something quite similar - same setup, osx and it only shows when using ansible. I'm on gnupg 2.2.3, also saw same using "GPG Suite 2017.2".

gpa not starting as well

Thanks a lot. Please note that there is a bit of possibility the messages which cause failure are one of attack vectors. (While most likely case is they are generated by broken implementation.)

Im mean GnuPG fails for messages from a particular sender, while it works for messages from other senders.

I only installed 3.0.2 this morning so this hasn't had much of a chance to happen.

Version 1.8.1. The full output is

OKay, mail lists. I didn't see that option but I will subscribe to the gnupg-users list and keep quiet. However in the mean while I can tell you that the removal of the configure options "--enable-large-data-tests --enable-hmac-binary-check --disable-O-flag-munging --disable-optimization " results in perfect test reports. Thank you.

Wow. Well thank you Werner becasue I have never seen the term used. It is precisely correct and yet the defacto style of the day seems to be "megabytes" but "mebibytes" is the correct term :

mebibytes is not a spelling error but the correct unit (abrev is MiB).

Your comments in the output were hard to find. Thus my comment to explain the bug.
You are using non default options and in particular the hmac binary check. The latter was written a couple of years ago for an older Redhat version and it might well be broken in the meantime.

Minor spelling typo :

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