I need to revise my statement (partly because fixing gpgme would be quite complicated). Marcus is right in that using the the literals_seen counter is the straightforward way to get this right. And it will fix it also for non-GPGME applications.

[We do things in the public unless explicitly requested by a bug reporter writing to security.]

I have changed visibility of the bug, as I think you can do a lot more with this than Marcus imagined.

Do you have a need for doing a new release immediately?

The set of information returned by gpg is too large to be mapped on an exit code. Thus we have status codes and the gpgv tool.

The impact is low to our current understanding, that's why I didn't report it as a security vulnerability. I tried to use this for signatures, but GnuPG has more verification for signatures, so it doesn't work there as far as I can see. So that's good.
If you allow for a BADMDC, you can easily downgrade the content of an encrypted data packet from, for example, compressed to private packet type, and then you don't even need the public key, just an encrypted message. The MDC will notice this, and since Efail the clients should have strict MDC checking, so I didn't include that variation in my report.
By the way, there are other clients I didn't test which are probably affected, such as kmail, claws, gpgtools.
I only have Outlook 2007 and no funds to buy software I don't use, as I am unemployed and using up my savings. So, next time I won't be able to do the testing, sorry!

Can you help me understand what the impact of this is? AFAIK Back in 2007 the problem was that it could be faked that data looked like it was signed.

Oh dear, adding new keywords which have not been reserved in the past was a bad idea by C11. This will eventually require fixes at lot of places because the noreturn attribute is widely used ( other common headers may include the noreturn header as well).

The primary function of those other tools is not securely encrypting data. If the message is too large to keep in memory at once, then there is indeed no choice to process it as a stream, but users should be aware of this. Perhaps a flag can be used, along the lines of --stream-without-verification? The man page could explain: "GPG computes an MDC over the whole message, so it can only check at the end whether the message was tampered with. This flag can be used to stream the output, so that the entire message does not have to be kept in memory. You must check the exit status to verify that decryption was successful and that the message was not tampered with, because with this flag, the data returned by GPG may be incorrect or even malicious. If the exit status is zero, then the MDC is correct and the message was not tampered with."

This looks similar to the "multiple plaintext" issue that we had in Feb. / March 2007.

Maybe the off_t mess comes from following line

I would also recommend that GPGME does a sanity check on the status fd output for people with new GPGME but old GnuPG binary.

Sadly deselecting a mail doesn't help always. Most of the time I cannot move the mails even then. So the only reliable workaround is to deactivate the Addin - what cannot be the goal, at least it is not mine ;-).

This is well-known and can't be changed without a lot of hassle. There is a work-around:

• Deselect the mail by selecting another mail.
• Drag-n-drop the mail to be moved.

The gpgme c api already had a convenience function gpgme_data_rewind to do data.seek (0, SEEK_SET); As this is by far the most common seek operation. KMymoney also only uses such seeks.

Sorry. gpg is a real software and not some memory hog. real software runs under Unix and complies with the Unix rules, where one of them is to allow the use in a pipeline. All standard Unix tools have this feature and you need to check the error code ("set -e" in the simplest case). It is not different from gzip, tar, curl, rsync, ...

In T3996#114721, @aheinecke wrote:

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

So what the error tells us is that "off_t" is defined as long in the declaration but as something else in the definition.

But how can that be? data.cpp includes the data.h header so they both should have the same definition of off_t.

The only thing I could imagine is that something which is included in the cpp but not in the header undef's off_t and defines it to something else.

Or more likely that the archive was compiled with a different definition of off_t then what is included in the headers when kmymoney is built.

Are you using the same mingw version as the buildchain which compiles the gpgme binary?

Uhm, yeah I would be willing to help. But I tried to understand it and don't see the problem.

You are not cross-compiling. This is not suggested and I don't have the environment to replicate this. Maybe @aheinecke can help.

Thanks, that allowed npth to make successfully without the unsatisfied symbols.

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!