Applied to 1.11 branch.

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

Pushed the revised change to master.

For argparse we use /etc as a default but applications may use gpgrt_set_confdir to set a different one. Howeever if we already have a new get_sysconfdir function, it is easy and useful to change the default on Unix.

In GnuPG we use CSIDL_COMMON_APPDATA and append "\GNU\etc\gnupg". If this can't be found we use the rootdir, that is he installation directory of the binary or one up if installed below a bin directory. The reason for using GNU and not POSIX or Unix is merely to avoid name clashes with other software ported to Windows. There was no real standard for this on Windows.

We already did this for Libgcrypt 1.8 but take care that an installer includig Libgcrypt should run something like

It is not an ADSK issue. The problem is that the new subkey has not been entered into the fingerprint table and can thus not be found.

Fixed in 2.5.13.

Thanks for the quick response. I can confirm the patch works in my setup.

Thank you for your report.

Note that:
If we consider backporting this to 1.10/1.11 branch, we also need to apply: rCdef1d4ea8f66: random:jent: Fix build with address sanitizer.

@jukivili
Thanks for your feedback.

There's GCRYPT_IN_ASAN_TEST environment variable check in tests/t-secmen.c and tests/t-sexp.c. Are those check needed after this change? Could they be removed?

For the initial attempt, I push: rCfe06287003a1: secmem: Handle HAVE_BROKEN_MLOCK for the case with ASAN.
This is better than nothing.

Note that currently Kleopatra (gpg4win 5 beta) fails to delete the key, which might impact other operations. I'm currently trying to figure out, if some other bugs/quirks are a subsequent error or not.

Workaround is to use --with-keygrip and delete both <keygrip>.key files. Problem here is that one part may be on a smartcard or one part might be shared (although not allowed) with other keys.

Right, it's the same with gpgol disabled. I set it to invalid.

But you are able to do this w/o gpgol being active?

Then I don't see how we can avoid this. It should be easy to reproduce this with gpgconf alone if you know how to use --change-options manually. Simply set the LDAP server that's already configured in the global config file.

Looks good to me on gpg4win-5.0.0-beta395 @ win11 (gpg 2.5.13).

gpgconf does not know about the global config files. Nor does it known about things like gpg.conf-2 etc.

I guess this is easy to explain:

1. gpgconf/gpgme reads the LDAP server from the global config
2. You add a second LDAP server (I don't think it matters if it's the same as the one from the global config or different one)
3. When you save the LDAP server then gpgme/gpgconf writes both LDAP servers to the local config
4. When you now read the LDAP servers you get one from the global config and two from the local config

I applied it to the 2.4 branch but please do not continue to translate for 2.4. 2.6 (master) is the new target.

Fixed in master: rGae431b04370f: w32:common: Take care of possible race on startup under Windows.

Pushed the change to gnupg master: rG61ff3759e827: common,dirmngr:w32: Fix for semi-hosted environment.

In libgpg-error, I pushed thread-safe version : rE0313b660f8bd: w32: Don't convert slash->backslash when it's under Wine.
I'm going to push similar code to gnupg master.

Hi, I've managed to reproduce this bug on the gpg4win-5 beta as well. I think the frequency has gone down, perhaps, but it is still present.