We should only allow this for v5. This way we get incentive to move forward. ed448 requires a newer version anyway and thus it is good to take this as an opportunity to also demand AEAD etc.

The branch gniibe/v5/448 has the implementation.

To be conservative, it's better to output non-zero-removed signature.

Thank you.

(forgot to upload the patch to the last comment)

I am fine with either way. The memcmp variant is probably cleaner to make sure all works as expected in all cases.

Thanks for the well written bug report and the fix.

So that you don't need to chase the downstream bug report, the problem from a user's perspective looks like this:

Or, we can use memcmp to avoid arguing semantics of strncmp, and make it a bit cleaner to avoid calling strlen multple times by put_membuf_str.

diff --git a/g10/export.c b/g10/export.c
index 98c4623cf..c7cfcfaa4 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -2133,14 +2133,15 @@ key_to_sshblob (membuf_t *mb, const char *identifier, ...)
   size_t buflen;
   gcry_mpi_t a;

We know that problematic strncmp implementation: T5443
So, I don't blame Coverity. But I think that it's better to fix strncmp implementation.

Under C11, it seems OK (strncmp).
https://stackoverflow.com/questions/38878195/does-this-usage-of-strncmp-contain-an-out-of-bounds-read

I applied most of gnupg-coverity.patch.

• Part 1 is not applied; It should be handled later.
• Part 2: applied
• Part 3: applied
• Part 4: applied, but spell fixes not require ChangeLog entry
• Part 5
  • ecdh part is fixed differently
  • export.c part is not applied for now, because of semantics/interpretation of strncmp; POSIX says differently although it says it's ISO C standard which defines. https://pubs.opengroup.org/onlinepubs/9699919799/functions/strncmp.html
• Part 6: applied
• Part 7: applied, but empty initializer is GNU extension (or the way of C++), so first 0
• Part 8: applied
• Part 9: applied, but one more fix

Friendly ping @werner

Has been merged into master.

In D538#5324, @werner wrote:

Having it invisible is okay for me. But we should not support the keyserver option in gpg.conf via Kleopatra anymore. This option needs to be faded out.

Having it invisible is okay for me. But we should not support the keyserver option in gpg.conf via Kleopatra anymore. This option needs to be faded out. Actually there are more problems in 2.2 here: In particular the global options are not manageable by a gpgconf. Thus there is no guarantee that the keyserver option actually shows the correct value if global options are used.

Pushed to branch ikloecker/t5462 for easier integration as rG0a7d772a5c43: gpgconf: Allow changing gpg's deprecated keyserver option.

I think we can close this bug. The warning will now only be printed as part of the the regression test and after all it is just a warning.

Fixed. See parent task for details.

It seems like this warning does break some usages of gnupg on macOS.
We found one when packaging this in Homebrew: https://github.com/tadfisher/pass-otp/issues/147

Thanks for the clarification. So it's just a matter of not emitting the warning I guess?

gnupg_bindir() uses unix_rootdir() falling back to the builtin configure time path if unix_rootdir() returns NULL. So, there is no difference.

I second this. This is problematic on (Free)BSD too, where /proc is usually optional and might not be mounted at all. I concur that this should be silenced if not running in debug mode.

Urgs, I already implemented this:

On macOS _NSGetExecutablePath could be used, but iiuc this requires linking against dyld. For other OSes we would also need more code. I doubt that this makes a lot of sense these days; but we should come up with a solution, even if that means we need an envvar to specify the location of that open gpgconf.ctl file.

No, the error is harmless. I guess it shouldn't be printed (except when debugging).

We now require a way to get the actual image of a process. For macOS the BSD method is used and we obviously need to find another way for macOS.

@rupor-github no problem for the delay. Thanks for explaining!

Fixed in 2.3.3.

Fixed in GnuPG 2.3.3.

Fixed in GnuPG 2.3.3.