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

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: