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:

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!

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.

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 )

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:

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

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.

Thanks. Confirmed - no crash with the beta5 dll.

Argh! From the log it looks very much like another incarnation of the issue fixed in T3960 (Same underlying reason)

Good idea, but I've already tried it. Tried once again and freeze still occurs.

Hi and thanks. Yes, I consistently reproduce. Here's the log file.

Okay, so maybe this has nothing to do with T3748 then…

That comes directly from pthread_attr_init - need to check what's special on HP/UX here.

Above command freezes with 100% CPU, too.

Thanks for your report!

If you never explicitly changed the default trust model, then I would expect you are not using TOFU, but the presence of a tofu.db file strongly suggests that you are indeed using it.

I'm not sure. How to check it? In man gpg I only see instructions on how to change the trust model. ~/.gnupg/gpg.conf does not have any trust model related entry. I have ~/.gnupg/tofu.db file however.

This looks reminiscent of a bug previously seen in GPA (T3748).

It seems that Debian does not install te required libgpg-error correctl.

I understand the Problem. Your recipient formatted the reply in such a way that GpgOL does not detect that the original message is Quoted, verifies it and shows only the verified part.

But why is that the case for OpenPGP Signatures, then? The difference does not make sense to me.

The key receives fully trust and thus we get the "green" flag plus the "expired" flag. In my test with OpenPGP the key was not trysted and thus we did not got only the "expired" flag. At some distant past we agreed on these rules.

gpgsm behaves exactly as gpg and as explain in doc/DETAILS. VALIDSIG is issues even for signatures done by an expired certificate. Let me check whey GPGME claims "green" here while it does not not an expired OpenPGP signature.

I think this issue is important as GPGME should not report "Green" / Everything OK in that case and only have the EXPKEYSIG in details.

1. Create Mail and sign with PGP/inline activated
2. Send mail to someone else who does not use gpg etc.
3. Get a response including full quote of your email

I changed the priority to 'Normal'. The problem now is not the libssh usage, but how we can assume use of secure memory by random generator(s).

By libssh upstream, the problem has been fixed: commit-72f6b34

Thanks for your report. Are you sure that "Allow HTML" makes the difference?

As I link this Ticket often when talking about this limitation. Here is a short animation to show what is meant by moving but not opening a mail:

I'm not sure I understand your Problem. For me it works as it should.

Here is the function:
https://git.libssh.org/projects/libssh.git/tree/src/dh.c#n227

Am I right to assume that the test suite is terminating and restarting libgcrypt? Although we have features for this, I am still not convinced that this is a proper use of libgcrypt. There are just too many cases how this can fail. Unix is not designed to use shared libraries in so-called "plugins". I need to look closer at the libssh code.

It would be better not to require gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE). Automatic handling through gcry_control(GCRYCTL_TERM_SECMEM) would be better.

The patch D461 makes gcry_control(GCRYCTL_CLOSE_RANDOM_DEVICE) free the allocated secure memory.

It assumes a change of libssh like:

Here is my patch: D461: jent random requires finalizer to deallocate secure memory

I downloaded it and I' m using it.
Nice feature the "notepad".... easier for encrypt/sign.

The latest Version of Kleopatra has a "Notepad" View that should do what you want. E.g. If you decrypt something in there it preselects the keys the message was encrypted to when you encrypt it again.

In T3963#114101, @aheinecke wrote:

OOooh yeee.
Ok. Didn't know how bad gpg4usb really is.
I looked into it. Gpg4usb distributes their own binary GPGME version https://github.com/gpg4usb/gpg4usb/tree/master/linbuild/lib I don't even know which version that is. They are in violation of the GPL as they don't offer the source code of that GPGME version.

So, don't use it please what they do is horrible from a security standpoint. Try using Kleopatra (which I personally maintain). And if it does not work for your use case please let us know what your use case is and we can try to make it better for you. :-)

But indeed for gpg4usb you can't expect help here. They are very likely shipping a horribly outdated version with bugs that have since been fixed.

Workaround is to click cancel so that the next key is tried; right?

I 'll try GPA and Kleopatra, I hope will do the same tasks.
thanks anyway.

I suspect gpg4usb is a dead project anyway. I've been on their mailing list for a while and according to my records the last post from the pseudonymous author(s) is from October, 2016. I'm not sure how much of that GPL breach is intentional or just a result of web services going offline and not being restored.

The Python portion of this is done, the tests will now create a key with an expiration a few years shy of the 2106 end date (NYE 2099).