Problem/Bug still persists in current version (gpg4win 3.1.16) --> reopen

GnuPG 2.0 reached end-of-life nearly 4 years ago. See https://gnupg.org/download/index.html#end-of-life . Same for Gpg4win. They are not maintained and its use is very risky due to unfixed bugs. Please update to a recent version.

Please use shorter password.
For gpgsm, maximum is 31 chars.

Thanks. Added to 2.2.

This was actually reported against 2.0.31 which reached EOL 8 months ago.

Sorry, the patch above is completely wrong, since pk->pubkey_usage is not the right key to check.

If someone claims this is a kind of vulnerability, I think that what we need to fix is signature checking side:

The bug is specific to 2.2, which may select available key on card. When such a selection, checking the PK->REQ_USAGE was missed.

Shouldn't this also be applied to STABLE-BRANCH-1-4?

I think that I located the bug and fixed. I wonder why Werner put gpg20 tag.

Same issue exists in 2.2:

A backport to 2.0 does not make anymore sense given EOF in 2 months.

No info received, similar to another fixed bug, and for 2.0 which will soon reach EOL.

2.0 will reach EOL soon and we have received no response. Thus closing. If the problem persists with 2.2 (e.g. from gpg4win 3.0) please re-open this bug.

Won't be fixed for 1.4.

@perske, may I ask you to send a DCO and an possible updated patch against 2.2 to gnupg-devel@ ? I would like to add it to 2.2.2. Sorry for the delays.

This looks suspiciously like T1547: gnupg >= 2.0.21 won't build on OSX 10.8.5 with XCode5.

gpgtools will have to update.

I just verified that this is indeed fixed.

I tried to find evidence that such a change ever landed in 2.0. I now believe the mistake is in the NEWS file. As 2.0 is nearing EOL, we won't backport this.

gnupg uses LC_ALL, LC_MESSAGES, LANG and the system default determined with GetThreadLocale() on Windows. Can you please check if you have set any of these environment variables?

Landed in 67cd81ed90ad88cbe607b7f7d1a0b1e08b8ac1f1.

The sqlite backend was a little experiement that I did and it will not be merged.

As the @neal branch has not been updated anymore, I wonder what the status of this report is. Do we have a canonical test case and a performance goal, or anything else that let's us evaluate this? @werner ?

No I don't recall any such problems, sorry.

For information, this issue was also discussed on both gnupg-user and gnupg-devel back in january 2017. I mention it here for reference.

@werner The backport to 2.0 didn't happen, I think. Is this still relevant. @justus Do you recall any more problems in the tests?

Any updates / thoughts on how this might be fixed?

Libgcrypt 1.6 reaches EOL in 7 days, so we won't fix it.

What is your operating system?

Hello Werner,

The problem is, that some projects liek gpgtools for MacOS are reluctantly sticking to
gnupg-2.0 :-/

So, I'd love to have this patch committed in order to ease the transition phase from

2.0 to 2.1 for them.

Regards, Wolfgang