The problem is with the code for T3656

Thanks for the report. I can reproduce this by replying to S/MIME enc & sign mails.

@Angel: The mail server log showed 0 bytes for the affected messages.

While triaging issues this looks to me more like a support case. And not an issue of the software itself. So I'm closing this issue.

As of now we doubt that the proposed patch helps and we even fear that it could make things worst. Thus, as long as there is we have no description of an attack we won't do anything about it.

Are they actually zero-byte mails, or is the content mungled as an attachment? (which those replying probably overlooked, and would still be hard to interpret, as it would containe MIME parts)

Although this is a standard behaviour for Unix tools, you are right that it makes sense to tell the user about the problems. And well, the version info should not appear either.

I observe the same problem since I installed gpg4win 3.1.11 (german) in Outlook, Office Professional Plus 2019, Version 2004: Occasionally "zero byte mails" are sent by replying to an s/mine certified and encrypted mail. In my case the option s/mine support is disabled in GpgOL menu.

Fixed in master and applied to 2.2 branch too.

Sorry, I was reading the next commit (libdns: Avoid using compound literals (3)).

I have to disagree. Unless I am not completely confused the modified functions use automatic buffer variable and then basically return it.

Robin H. Johnson created a patch for this on gnupg-devel@gnupg.org in Message-Id: <20200520052643.23627-1-robbat2@gentoo.org>:

Possibly, it would be dns_p_init which was caught. If so, it's false positive; It returns a pointer given to the function (which is automatic variable of parent function), but it is valid within the scope of parent function.

Could you please show more information, a specific point of the bug?
I can't locate any place where a function returns a pointer to automatic buffer.

Seems to be fixed now.

Closing with Info Needed.

Okay, makes sense.

No, it is widely understood as a means for reproducible builds and specified at: https://reproducible-builds.org/docs/source-date-epoch/

SOURCE_DATE_EPOCH is NixOS specific?

Well, I had simply accepted that the rule for defsincdate is always triggered. I looked a bit more into it, and the cause for triggering is that Nixpkgs patches dirmngr.texi, hence defsincdate is cleared by the rule above and the fallback behaviour is triggered.
But this also means my suggested patch wouldn't help here as the modification date of dirmngr.texi would be picked up.

Looking at the rules I do not understand why we have a problem here, the rule

I think an option to ignore certain files is a better way to do this. I'll give it a try.

"Wyszukaj na na serwerze..." has been changed to "Wyszukaj na serwerze..." and should appear in the next release of Kleopatra.

Thanks for the logs. I can see the crashes, but I can't make heads or tails of them. We crash in completely valid code. I really don't want to play the blame game here but to me this would be explainable if there is an issue with refcounting in the GFI plugin that would release the IMessage or ISecureMessage MAPI Object from the ItemLoad event once to many. In that case the object we work with might be deleted at random times and that would explain it.

After looking at this for 4h I could not see a way to detect it better when a print job is done. So we now treat every ItemLoad of a mail after we have seen the BeforePrint event as a print.

Outlook is a bit nasty here:

I added the log file.

Thanks. Applied. Will go into 1.4.0

It'll be fixed soon. Please use https://sourceforge.net/p/kdei18n-pl/mailman/kdei18n-pl-uwagi/ next time.

could you please go into the GpgOL setting and under "Debug" turn on logging on the highest level (+code trace) and then reproduce the crash and add the log here?
Including Data should not be needed so you can keep that checkbox unchecked to avoid having mail data in the logs.
This might help us to see where and why the crash occurs.