please see the branch dkg/fix-T3995 with rG3308d5e3f4e25dce5168c4a7cb2f545424c6d185

Apparently, the check of sem_init function was not done (in config.log).
Could you please make sure to update npth/configure by npth/autogen.sh?

config.log is attached.

The best way to send signed or encrypted mail is by using PGP/MIME which is the default.

Could you please put the config.log of npth with the patch?
The intention of change is: we need to link -lpthread and -lrt

Thank you for your answer.

I tried with the updated patch, but I still see the same unsatisfied symbols during link. I verified that the patch was in place in configure.ac and also patched a clean version of configure.ac so that there would be only one instance of hpux in the case statement:

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.