Things have been a bit buggy here (probably, since the beginning).
In g10/trustdb.c,

Let me clarify:

• It was on 2003-11-01 (ChangeLog is on 2003-10-31 probably in US): rG5c37fd90bf81: * trustdb.h, trustdb.c (register_trusted_keyid): New. Adds a keyid to the

That seems to (mostly) work partially fix PowerShell pipeline output at least:

The problem was the error handling.
I didn't apply the patch directly, but improved the code paths.

https://bugs.kde.org/show_bug.cgi?id=447326
This problem also appears for trojita.

Will go into 2.3.4.

Things are not that easy. I actually introduced a bug in 2.3.4. Here is a comment from my working copy:

Adding comments, fixing "const" qualifier, I pushed the change.

A patch created:

GnuPG 2.2 does:

• In g10/sign.c:do_sign, it keeps leading zeros for Ed25519 signature, as opaque MPI
• In g10/build-packet.c:do_signature which calls gpg_mpi_write to output the (opaque) MPI, leading zeros are removed.

Hmm,

$ gpg --with-colons --list-config curve
cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1

How would Kleopatra know that cv* is for encryption, ed* is for signing, and all other curves are for both uses? Or are the cv/ed prefixes a (de facto) standard?

You may run

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, given the situation most implementations already support zero-removal and zero-recovery, it's better to output zero-removed signature, that is, signature with well-formed MPI.

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.

I should have explained the context.
No, there is no discussion about this in the WG.

The new bugs have been fixed in 2.3.3; see T5565.

@bernhard Sorry for the delayed answer, was on sabbatical.

Is that really required? Should we wait what the conlusion of the WG will be?

I'm reading RFC5297, which says:

SIV can be used as a drop-in replacement for any specification that uses [RFC3394] or [RFC3217], including the aforementioned use. It is a more general purpose solution as it allows for associated data to be specified.

Note that I'm referring to file based keys, not card based.

I tested this on 2.3, and it doesn't seem to be fixed. When adding an existing ECDSA subkey I don't get the option to choose whether to make it a signing or encrypting subkey. Instead it only allows me to choose an encrypting subkey.

OpenPGP requires the P < U property and gpg does also. In some parts of the GnuPG we re-calculate the CRT parameters but not in these code paths. Right, a better error message would be appropriate. I'll turn this into a feature request.

In that case maybe GetUserDefaultUILanguage. Thank you for considering.

Thanks for the info.

Major problem here (before the change) was that clock_gettime returned an error with no valid value of the time, which confuses gpg-agent's calibration of time. This occurred on (not newest) Solaris kernel, as it offers clock_gettime function in the library and CLOCK_THREAD_CPUTIME_ID constant in the header.

I mentioned the two POSIX getconf settings you referenced in those links, and the developer that implemented CLOCK_THREAD_CPUTIME_ID and a couple other CLOCK_THREAD types had this to say:

FreeBSD has _POSIX_THREAD_CPUTIME > 0.
GNU/Linux has _POSIX_THREAD_CPUTIME == 0, because older kernel doesn't support the system call.

Reading pages of the following links:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_gettime.html
https://docs.oracle.com/cd/E36784_01/html/E36873/unistd.h-3head.html

Hi gniibe!

For 2.3, when you use PC/SC, please use the disable-ccid option in your .gnupg/scdaemon.conf.

Well this seems to be a gcc 4.2 bug. But well, forward declarations should go into a separate file so that tehre is only one place which would require changes. In this case it does not matter.