You may start the gpg-agent by hand:

In T4978#135418, @werner wrote:

The 5 second timeout is to give the agent time to get ready and accept connections.

The problem is that I have not yet found a _portable_ way to detect proper working v6 or v4 networking without doing a test connection. For privacy reasons we don't want to do that.

The 5 second timeout is to give the agent time to get ready and accept connections. I can't say with this infor why it takes longer at your site. Can you please try without putty support?

That is unfortunately not possible because there is no fixed link between the key and the rev cert. Instead they are linked via cryptographic signatures. The pre-generated rev certs are a fail stop measure in the case that the user lost access to the private key and can't create a revocation with a concrete reasons etc.

Any news on this?

Thanks for explaining; this may indeed lead to a followup processing error of correct data. However, I don't expect to ever see a fixed length header of 2GiB or more because the sender would have had to buffer all that data in the first place.

Please describe the problem and don't just paste compiler output.

This appears to still be a problem, despite upgrading to libksba 1.4.0:

Cool, thanks for fixing this!

Argh, I had overlooked that you even mention a pull request.
So Apologies that I did not attribute the fix directly to you.

Thanks for the nice report. The fix was completely straightforward, I just didn't think about rich text when I implemented it.

Thanks for the info. So I guess me added that restrictions to be on the safe side regarding the VS-Nfd evaluation. For 1.9 we can and should lift that.

Please see [1] appendix F - I tested it more or less on all major CPUs, small
and large, old and new:

AFAIK, Stephan evaluated it only for x86, let me ask him ...

Done.

Thanks. I bumped it up to be in sync with GnuPG 2.2. It also does not make sense to require a Libgcrypt which has reached end-of-life; Thus we now need 1.8.

I bumped up the requirement to 1.25 because we also use error codes defined there. To be on the safe side with older distros I defined the missing error code instead of requiring 1.27.

Thanks for the report.
I now describe the shortcuts as development and 2.2 stable branch.

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 completely confused the modified functions use automatic buffer variable and then basically return it.

Robin H. Johnson created a patch for this:

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.

The fix has been submitted to Kleopatra master

@aheinecke right, it's also fixed.

hello
thanks for the feedback
it s indeed exchange 2007 (migration planned on long term)
we will try the imap workaround

There was a similar Problem in the past reported on our mailing list:

Thank you for your work, appreciated. Sorry I was a bit under the weather in April and could not get back to you earlier.

Thanks, I can reproduce the problem. I'll look into it, printing mails is important for some ;-)

@aheinecke thanks for commenting.

Does it decrypt then?

This is not the first report I have gotten about mailstore problems. My suspicion here is that the mail is opened read only or somehow got the wrong properties from mailstore.

I can reproduce this.

I've just tried the test suite of GnuPG 1.4.23 on debian buster and all tests pass.

I keep it open as testing so that we keep it in mind for a release.

There was a patch for this by david faure which added an
#undef ttytype after including curses.h

I'm working on better support for Smartcards and esp. multiple smartcards in Kleopatra. IMO it should not be required for a user to explicitly write a reader port in the config.