Backported for VSD 3.3

I'm wondering whether we are hit by undefined behavior. https://en.cppreference.com/w/cpp/algorithm/sort mentions some conditions that must be met for (un)defined behavior. Or it's a bug in gcc or gcc's STL. I added some debug logs to the comparison lambda. The first comparisons look fine but after a certain number of comparisons it crashes in the debug logging (when it tries to access the primary fingerprint).

When VSD33 has been updated to integrate the fix/commit then this can be closed (i.e. set to vsd-3.3.0) without manual test, in my opinion.

The (rather trivial) changes where reviewed by Sune. And it's not really a very important issue. Therefore, I'll set it directly to resolved.

Merged to VSD33.

Since it is only me, let us set the "Wishlist" priority on this task.

Not much QA can do here.

Can't find a mail - closing the ticket. Feel free to reopen or send me a mail to werner dot koch at gnupg.org but replace the org by com.

Tested in Qt 5 build Gpg4win-4.3.2-beta23: Configuration dialog looks good.
Qt6 was tested by the developers

Applied in: rCdc8d84383a6b: cipher:aeswrap: Fix padding length check.

For my testing environment, I have this patch for now.

Testing dirmngr by /home/gniibe/build/mingw-i686/gnupg/bin/gpg-connect-agent.exe --dirmngr 'loadswdb --force' /bye (configured distsigkey.gpg beforehand), I confirmed it works well now.

Fixed in: rG862448216035: common:w32: Fix INEXTRA handling.

All applied and more fun with cherry picking in the future ;-)

This is related to T6818

Recall that on windows you have a current working directory per drive. Thus only LETTER:\foo is a full patch - or an UNC (\\SERVER\foo).

The executable is on Z: drive (Z:\home\gniibe\build\mingw-i686\gnupg\agent\gpg-agent.exe) in the emulated environment.
Perhaps, when the path is absolute path with /, it is interpreted as on the drive Z:.

An update FYI

fwiw, i've just shipped a patch to correct this change in behavior in the 2.2 branch debian. Many thanks to @gniibe , on whose work in the 2.4 branch this is based, and to @ametzler1, who did the backporting to 2.2. I've also written a test which tries to tickle this bug. It fails with unpatched 2.2.43 as emacs times out signing and encrypting mail as epg.el deadlocks with gpg.

Thanks for your answer, @werner

Do not use the pcscd but the integrated CCID driver. This is actually the default form Unix. Or are you on Windows?

All fine. I just noticed it while checking the patch. All applied and more fun with cherry picking in the future ;-)

Hello all. I think I am affected by this problem (I get asked for the yubikey PIV pin every time I make a git commit).
Is there a known workaround?

that looks like it was a problem in the original text, not something i introduced. If you find anything else that needs fixing, please go ahead and fix it to! no need to wait for me.

I left review comments in gitlab.

Right away the first patch:

Backported to 2.4 and relevant parts also to 2.2

We discussed this forth and back with the RedHat people at our jour-fix to explain that the Kairo fix is done at the wrong layer - this needs to be done at the protocol layer and not in the building blocks. This is not covered by our security policy and @gniibe already came up with some extra support to help at the protocol layer. There are only a few use cases where this side-channel or the Minerva one (for ECDSA) should be considered (e.g. time stamping services). Generally required protection against DoS are also pat of the mitigation.

I left review comments in gitlab. One additional concern is license for mpi-mul-cs.c, original code not having copyright information... "does not have any copyright information, assuming public domain".

In T7129#186556, @werner wrote:

In PATCH GnuPG 12/15] sm: Avoid use of uninitialized variable I can't see where ERR was not initialized.

All except the above mentioned applied to master - will be backported to 2.4

In PATCH GnuPG 12/15] sm: Avoid use of uninitialized variable I can't see where ERR was not initialized.

Fair enough. This is more theoretical and could happen only on huge reads. Using ssize_t for read() return value is safe option, but really does not make sense to adhere to it in cases where the reads must be smaller.

I do not understand why there should be an integer overflow:

This is not a bug. We changed it as a convenience for some Emacs users.

Are you saying that concern about "risking a regression" is the reason to not fix this bug, which is itself a regression, and was introduced into the a point release in the current "long term support" branch?

Sorry, no. The change is too large to back port it w/o risking a regression. As mentioned in T6481#170366 I don't consider this a bug. We are anyway working towards version 2.6 which will be the next LTS version.

Any chance this could also be fixed in the 2.2.x series, where it seems to have been introduced in 2.2.42?

Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.

Well, but if the padding is indeed limited to 7 bytes the fix should be applied anyway.

The report went like this

Error: OVERRUN (CWE-119):
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:303: cond_at_most: Checking "plen > 8U" implies that "plen" may be up to 8 on the false branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:305: cond_between: Checking "plen" implies that "plen" is between 1 and 8 (inclusive) on the true branch.
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:309: assignment: Assigning: "i" = "0".
libgcrypt-1.10.3/cipher/cipher-aeswrap.c:310: overrun-local: Overrunning array "t" of 16 bytes at byte offset 16 using index "8U + plen + i" (which evaluates to 16).
#  308|   
#  309|                 for (i = 0; i < 16 - (8+plen); i++)
#  310|->                 if (t[8+plen+i])
#  311|                     {
#  312|                       err = GPG_ERR_CHECKSUM;

but looking again, it is wrong as it did not reflect the end condition for the cycle, which obviously means the cycle does not run. Sorry for the noise.

Can you give a hint where there is a buffer overrun in the first patch? Padding limit might be correct but I can't see an overrun.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

Thanks for running the analyzer. We need to have a closer look at the suggested fixes. For example initializing a variable needs a reason and should not be done as a general precaution because that may hide other errors.

Back in the ancient days we allowed to dlopen algorithms so to avoid patent problems in certain countries.

Thanks! please consider adding it to 2.2 and master as well. I suspect it's more outdated than it would be if it had been shipping in the upstream tarball.