Our tentative plan is:

Good catch, we need to update at several places.

FWIW, in GnuPG we use

You are coming pretty late to the party ;-). Since 2.1.0 we don't use the ancient keyserver helpers anymore but reworked the entire network access. I even doubt that I can still test with a 2.0 version.

We have two or three other open issue which I would like to address before a release. FWIW, release ticket is T5305.

Do what ever you want with _gcry prefixed functions - this is never considered an API or ABI break. There are some exceptions for internal functions used by macros but those are clearly marked.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

Yet another identify theft scam committed by clang.

Please look at the code:

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

--clearsign may only be used for plain text documents due to line ending conversion etc.

Sorry, this is not a help line. Please use one of the the mailing lists or the gpg4win fori for ask for help.

The flag value is now 144 and not 146, but that extra bit (value 2) did not make sense for the option. So I think things are okay now.

Test comment after server migration.

So Facebook simply does not support Ed25519 keys; there implementation is a bit limited. To be fair, there is no published RFC describing 25519 for OpenPGP; all major implementations work with drafts regarding 25519.

Things are working out nicely and thus I am convinced that we will miss that whooshing sound the deadline would make as it fly by.

Given that all subtasks are at least in testing state, we can close this bug.