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.

Pretty outdated, but I add it nevertheless to 2.4
s/gnupg-2.4/po/nl.po: 1320 translated messages, 625 fuzzy translations, 268 untranslated messages.

Pushed the fix: rGbb57c808b2ad: scd:openpgp: Fix PIN pin2hash_if_kdf.

Thank you. Applied by : rM87061c0260bb: gpgme.m4: Set $host correctly always.

Ditto for ksba and assuan.

Done for gpg. Needs to be done for gpgsm.

The gcrypt change works for me. Thanks!

I note that @DemiMarie offered a patch for this over a year ago. It doesn't appear to have had any review. If it's good, maybe apply it? If it's problematic, can we identify the problem?

Thanks, I confirm that this new commit is fixing the issue.

In general, asking an application change is not good. Migrating to pkg-config should be an option (not requirement).
However, it's usually recommended to use libgpg-error when an application is used with libgcrypt/libksba/libassuan.

by all means, please proofread it! thanks for the attention to detail. what was the grammar glitch?

I still spotted a grammar glitch in corrections. Thus if we apply this we need to proofread it.

Thank you for testing. Now, I can see the exact reason by your npth log.
Pushed another change: rPTH75c68399ef3b: Fix previous commit.

Build is still failing even with this commit, here is an extract of npth log:

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

Thanks for report. I've applied this change to master.

The official GPG binary from "c:\Program Files (x86)\GnuPG\bin\gpg.exe" does not exhibit this problem. I will report it to the msys2 folks.

Yes, it is the msys2 build of gpg, installed using the standard msys2 methods. The pwd in my example was from msys2 zsh.
I reproduced the error running under msys2 zsh and in Powershell.
If I understand your response correctly, you are saying this will not be fixed in gnupg itself? I can report it to the cygwin/msys2 folks of course, if you think that is best. But I still suspect the root cause is in gnupg, probably in homedir.c or the code that makes an absolute path from a relative one.
I will retest with the official gpg4win and let you know the results.

pwd is not a standard Windows command. It is availabe in powershell but there I get

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.