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.

Thought of a way to at least mitigate it. When a mail is closed we know it's not printing.

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.

Won't fix because there is no need for it. ASN.1 modules are the formal description of a protocol and as such not copyrightable.

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.

I see no reason to not allow decryption of an entire folder recursively. The user knows what they are doing by right-clicking a folder instead of a file. You can show a progress dialog with a cancel button.

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

The fix has been submitted to Kleopatra master

@aheinecke right, it's also fixed.

Basic en- and decryption test against Governikus_Signer has now been done. Beware: I had to add a debug option to gpgsm to workaround non-compliance in algorithm support of Governikus; see the rG68b857df13c8a4e6cae5e3a29fd065bf90764547 for details.

Cool. Falls du einen Korrekturleser für die neue Fassung brauchst, sag gerne Bescheid. Ich hab da Erfahrung …