No problem. Both patches look good.

Does these patches look ok? @gniibe @werner

Thanks. All my tests work now.

Cool. I did some quick tests with 2.2 on my pretty old X220 and it really makes sense to apply the patch there as well.:

It was the bug of generating AEAD packet, which does:

Sorry for pushing immature fix. I located the cause, but I didn't have enough concentration for fix.

Just more background what I'm doing with these tests. I started testing with set of different sized test files (generated from urandom) to detect any bugs in my changes, which try to reduce amount of memory copies in iobuf_read/iobuf_write. Size ranges for these test-files are 0...17408, 32256...66560 and 130560...132096 bytes. These files are encrypted with different settings (public key/symmetric/cfb/ocb/different algos) and then decrypted and decrypted file compared to original.

I tested the fix. It appears to break OCB encrypting files shorter than 65515 bytes:

$ gpg --batch --symmetric --passphrase=bug --output=enc_065514.gpg --rfc4880bis --force-aead --cipher-algo AES128 --compress-algo none plain_065514
$ ls -laF *065514*
-rw-rw-r-- 1 jussi jussi   100 Feb  22 18:51 enc_065514.gpg
-rw-rw-r-- 1 jussi jussi 65514 Feb  22 18:42 plain_065514
$ sha256sum plain_065514
5711955703f4d96f510ad5a660c3ccd0d01f0b2dd2561ba6586159ad941cbcde  plain_065514
$ gpg --batch --decrypt --passphrase=bug --output=- enc_065514.gpg | sha256sum
gpg: AES.OCB encrypted session key
gpg: encrypted with 1 passphrase
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  -

In T5837#155062, @werner wrote:

Setting the management key has been implemented only for Yubikeys. So for Gemalto this won't work.

It would be awesome if you could implement this \o/

Let's try this for 2.3

Saw this again and the commit was not in the Stable 2.2 branch. I have cherry picked it. This should resolve this issue.

Backported to 2.2, too.

No, these are simply the technically available algorithms. I'll see what I can do.

Thanks for diving into the history of that code.

Here is the backport to 2.2:

In the original code, register_trusted_keyid is used in keygen.c, so that it updates user_utk_list, thus, will be into utk_list.
This should be done, by adding the keyid to utk_list directly.

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.