It works (or rather fails to decrypt) as expected, though an update to the HOWTO and examples is also needed, not a major change.

Since 1.4 has been previously cited as the thing to use when accessing data encrypted with v2 keys and the like, it's hard to argue in favour of backporting a fix for an issue which will explicitly override the one major use case (maybe one of two if we count headless systems still) for keeping 1.4 in play. If you were going to fix it and and potentially kill the use of it for accessing old archived data then why not just skip the backport and EOL the branch? Less work, same result.

I realized that the test case is already there.
I'm not sure the reason why make check for npth works well on HP-UX (before the my patch). It uses npth_attr_init (hence, pthread_attr_init) in tests/t-thread.c.
Perhaps, libtool is clever enough to detect -lpthread into src/libnpth.la (dependency_libs), I suppose.

Thanks for your testing, it's near. Here is updated patch:

Rebuilding npth results in three unsatisfied symbols:

I've tried to prevent the download of external references selectively for S/MIME Mails. There is PR_BLOCK_STATUS but I was unable to stop the question for the user if she want's to download the external references anyway. :-/

Yes, I checked and I can indeed add multiple keys.
No, that does not solve my problem.
Because I absolutely need to be able to see exactly what I am doing and in this respect the previous version (as it still is on Ubuntu) is much, much better.

Thanks for your report.

Thanks. I'll look into it. It's possible that in our tests we only changed the complete date.

Thanks for the report.

Thanks for the report. This is indeed a bug.

If you click on the grey question mark in the "Entry field" when adding recipients you get a dialog that lists all keys and also allows for multiple selection.

Thanks for config.log of GnuPG. I think that I located the problem; While gpg-agent should be linked to -lpthread, it was not. The configure variable NPTH_LIBS in config.log doesn't have -lpthread. Thus, pthread_* are linked to the ones of stub, and it resulted the error.

I have uploaded config.log. Let me know if you need any additional information/files. Thanks!

The bugreport was about "use existing key" selecting keygrips and I did try to use "change-usage" (for NIST P-256).

What you try to do is very special and not directl supported. You need to find the keygrip of the subkey (I guess you know that) and enter it as "use existing key" in the add-key sub-command. To change capabilities use the change-usage sub-command which is described in the gpg man page and the online manual.

This is a screenshot I received in November. What is shows is that Enigmail got the error from gpg and displays an error. However, the plaintext is also displayed (the garbled stuff) and would thus trigger the explot. But first the user has to agree to it (the blue TB warning). So this screenshot actually shows that the exploit did not work.

Thanks for quick feedback.
Yes, it is a build problem, which should be handled by configure + make.
Could you please upload the build log here, so that I can check it to fix configure.ac+Makefile.am?

Thanks. That appears to be the exact issue. I was able to get around it with export LD_PRELOAD as indicated in the man page. Any ideas on how to address it in the make? This is what I see when I do an ldd on gpg-agent:

ENOSYS means it's linked to stub.
http://nixdoc.net/man-pages/HP-UX/man5/pthread_stubs.5.html
Somehow the build process may be wrong for the gpg-agent executable.

Have to test it but I think its resolved. The registry path handling is now similar to that of GpgOL and GpgEX.

In another report, it turned out to be, that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

The path I now took is to keep 2.2 as is but change GPGME to trigger a decryption failure if no MDC is used. This is under the assumption that old scripts using gpg 2.2 or gpg 2.0 do not use GPGME.

Please update to Gpg4win-3.1.1 this issue should be resolved. There was a similar issue with Gpg4win 3 T2670 but it has been resolved.

We've analyzed another report of this and the problem turned out to be that with a 64 bit outlook and GnuPG not installed in the standard location it came to this error. ( T3988 )

@werner I was hoping to make a modified gpg-agent build that would let me walk through what's going on after the nonce is sent but it looks like the gpg4win process only takes in a package of pre-built gpg binaries which rules that out. As far as I can figure out, after the nonce is read and accepted, libassuan creates a stream object out of the socket and then finding nothing in the stream terminates the ssh handler. We send the actual client request immediately after the nonce but in a separate call to send() so I now wonder if by not having anything read in at the same time as the nonce gpg-agent or libassuan thinks that it's a 0-length stream.

Yes. For S/MIME we don't have the comfort to change the standards. I also would like to have a quick solution. After much deliberation with Bernhard we think that it is a good compromise from usability vs. security that we further reduce the usability for S/MIME in that we only allow (any) signed content to be displayed as a file or HTML. This is not extending the standard, not changing GPGSM but a design decision in GpgOL.
We don't have full control over our Mail client so we can't prevent the load of external references like KMail does. This suggestion is a compromise and a pragmatic solution.

You mean because they mentioned 64 bit block ciphers? In the original mail exchange in November about "we have broken the MDC" which we disproved and they confirmed that it is an Enigmail or Thunderbird problem:

That was actually our old stance on OpenPGP encryption: For integrity we rely on the signing of messages. Remember that signing is an integral part of OpenPGP messages and does not need MIME. Some people explained that they have valid reasons not to sign and so we added the MDC.

Actually this is not related to the mentioned CVE because the issue we are talking about has not been tested by them.

Yes, this is on purpose, we display only the most important commands, similar to --help

Thanks for testing. A new Gpg4win release will come soon.

Actually this is not related to the mentioned CVE because the issue we are talking about has not been tested by them.

Done in master with rGd1431901f014 and we are discussing on Jabber whether we can risk to do that in 2.2 too. It might be that another ortion than --ignore-mdc-error would be better for 2.2 but that would differ than from master.