Fixed in master and applied to 2.2 branch too.

Important interoperability issue:
OpenPGP implementations should implement:

• Recovery of leading zero octets for Ed25519 key handling (secret part) and Ed25519 signature

Better to paste directly:

# SOS representation
#
# Initially, it was intended as "Simply, Octet String", but 
# it is actually "Strange" Octet String.
#

I wrote this:

libgpg-error used to be blamed because of this kind of architectural support in earlier stage of building operating system.
T4774 is my try to fix the problem.

Thank you for your work. Please go ahead.

If there's no objection to this in a few days, i'll go ahead and merge it to master.

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:

I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

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.

branch dkg/fix-4952 contains this fix in an easily applicable form as 0db8c768843db3e85935b972f1ed9d1b98159c46

Seems to be fixed now.

Parsing and creating of certs does now work. I was not able to find sample CMS objects so this part is not yet finished.

Finished if an existing key is used. See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples.

See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples on how to create a cert

This was implemented 0d2db8b81ab24e2ab02d7ba6832cabd07b72f852 in Gpg4win-3.1.11 but does not work reliably.

Closing with Info Needed.

I'm moving this from testing to open again. Especially the deletion is an issue. I had a report that even for a sent mail Outlook.com also stores an unencrypted variant in the "Trash Bin".

Works nicely

This was released in December 2019

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.