This was a very clear crash that is fixed now. Length was > 76 characters. This caused an improper realloc.

Even after running additional tests like converting the file to reStructuredText, fixing any remaining possible errors and then converting back, the result is that org-mode still appears to save the source correctly, but cannot export it in a correct format with babel. Certainly not to XHTML and likely not to any other format either. So that's definitely a bug.

Massive overhaul of the entire document performed in this commit.

Fixed for 2.2.9.

To be released with 2.2.9

I noticed while looking at Netkey V15 (that signature card) support that we actually didn't have Netkey v2 in the whitelist for supported cards anymore since at least gpg4win 3.0. So I've updated this list accordingly.

What happened to the once existing Netkey Card v2 support?
Is it gone or should it rather be "Netkey v2 & v3" in the commit above?

Some times I a curious and it seems that GnuPG can be used on 32 bit Cygwin. Thus I wonder what is going on on 64 bit Cygwin (which I don't know). It might be a HANDLE/socket issue where Windows is still using values which fit into a 32 bit integer but Cygwin might have changed that. Eventually we need to remove that assumption in GnuPG's code and this is why I won't have a problem to keep this bug open.

Agreed, after the verification succeeds the caller can (and probably will) check the signature notations.

Given that Cygwin is not supported I would understand if the bug is
closed or should I open a feature request to have Cygwin officialy
supported.
I would never the less appriciate any help/hint on how to be successfull
installing "gnupg" on Cygwin.

Note that Cygwin is not a supported platform. Seems that the exec functions don't work on this 64 bit variant.

re: last question: Marking a notation as recognized does not mean gpg does do anything with it or that it demands this notation. The latter can be handled by the caller. For example, gpg knows about "preferred-email-encoding@pgp.com" but does not apply any semantic to it.

Sorry, I meant the key pair (thought bundle) of private and public key.

No problem. I am glad that it works.

Boh. I've retried today, and seems to work as expected:

@Breach I was analyzing T4056 and wondered where I had seen the error from there before. And I found it in your log.

Actually the --locate-key command differs from the implicit use of locate key code when encrypting to a mail address.
After importing the expired key and running for example

Won't fix for 2.2 or CFB encryption.

My bad. I looked at the wrong working copy. Will pick that commit.

No, it is your fix: rG278d87465685: gpg: Clear the symmetric passphrase cache for encrypted session keys..
Please cherry pick it to 2.2 branch.

Slight addendum: MSYS2 isn't even part of MinGW at all, see the commentary in this bug report. Nor is it a part of Cygwin, but apparently it is a part of a fork of Cygwin.

Not only is this not supported, but I've now confirmed that MSYS2 isn't even supported by its own project and they direct all downloaders to their MinGW-get installer.

Thanks. The entire getkey.c code better needs a complete overhaul for before we add v5 keys.

We have a workaround thus lowering the priority.

It seems @gniibe fixed that en-passant in master. At least I can only replicate this with 2.2.

Ok yeah. I can aim for a Gpg4win for next week, too.

next week?

What is the ETA for 2.2.9?

Finally changed it. Especially for keyserver search this was important.