Thanks for your report, but as JJworx already said this is sadly one of the known issues to which we don't yet have a good idea how to fix it. In T3459 there is an animation what is meant by "unselecting" the mails.

Yes, this is actually pretty high on the wishlist but AFAIK there was not yet a task for this.

I justed commited some gadgets to gpgme which might be helpful But please show warnings etc before you use that new option.

There won't be anything without MDC in 2.2.8 anymore.

In addition GnuPG master and 2.2.8 now always create MDC messages (except with option --rfc2440) and always fail for messages without an MDC. For old algorithms a hint is printed:

gpg: WARNING: message was not integrity protected
gpg: Hint: If this message was created before the year 2003 it is
     likely that this message is legitimate.  This is because back
     then integrity protection was not widely used.
gpg: Use the option '--ignore-mdc-error' to decrypt anyway.
gpg: decryption forced to fail!

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?

@gouttegd Thank you very much!

Following in-person discussion with @werner last week, I have now added this EFL pinentry to the master branch of pinentry (commit 948105b).

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).

@werner, what protocol design rule do you think is not being followed specifically?

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, ...

From the autocrypt page:

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?

Let me state it again: Using symmetric encryption for authentication is Bad Thing™.

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.

Please discuss this at gnupg-devel. A bug tracker is not a useful here.

I wonder if there's potential for engaging users remotely? Also, in addition to a workshop, maybe a user interface study of how users learn and interact with the tool? I feel like doing that with people who are relatively light/new users of gpg (like me, currently struggling as I wade thru a mix of docs, some of it outdated) could be beneficial. See also: https://arxiv.org/abs/1510.08555

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