works with Gpg4win-5.0.0-beta395, too

Please show the command line of the linker.

Great, thanks!

I considered to make the --display argument optional but that still leads to the error. Thus better do not set or send it at all. I did this now for all gpgme engines.

I checked the code under gnupg/dirmngr. Those are no harm.

There are a lot of other ways to confuse the user. We can't fix them all because the whole purpose of a cleartext signature is to make it easy to use in legacy environments like an BBS. Modern systems use MIME to handle this in a more stringent specified way. For any use it is stongly suggested to check the actual signed data which is avaialable with the --output options. At least a sanitizing viewer should be used which filters out all escape characters (something like cat -v |less).

We have seen wrong encodings quite often in the past and thus we won't apply the patch. After all the armor header is a different layer and could also be applied or removed by other software or tools. The integrity of an OpenPGP message does not depend on its concrete outer encoding.

For someone who considers the rejection is the requirement of the spec., here is a change:

Here is a revised patch (hopefully the last one):

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):

Here is a patch (revised since the email of mine):

For t-stringhelp.c, here is a fix.

For

openpgp_oid_from_str has a wrong memory-safety assumption

For Integer Overflow in literals_seen, I think that the claim is wrong.
When literals_seen becomes two, GnuPG stops processing to return an error.
It's not possible for GnuPG to keep processing.

For Integer Truncation of Arguments report, since the int value is limited to one-octet value, we could add check for the length of input when we use strtol.

We have fixed it but the commit also states:

I agree because the original purpose from the 90ies to enable the use of signed patch files in the Linux kernel community was never actually used and GnuPG stopped the distribution of patches from version to version many years ago. Thus I agree we should hide this option behind a compatibility flag.

Added a compatibility flag in: rGad0c6c33c3d6: gpg: Do not use a default when asking for another output filename.

Fixed in rG115d138ba599: gpg: Fix possible memory corruption in the armor parser.

Fixed in rGdb9705ef594d: gpg: Avoid potential downgrade to SHA1 in 3rd party key signatures.

Fixed in rG8abc320f2a75: gpg: Error out on unverified output for non-detached signatures.

This feature should be only enabled with a compatibility flag.

Mitigation would be: adding context validation in add_onepass_sig function, which checks WHAT of armored input.

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.