You are using the basic pinnentry which comes as part of the basic installer. Almost everyone does not use this but Gpg4win which has a real pinentry. See http://gpg4win.org You don;t need the program statement then because gpg is installed in the PATH.

Actually we have two gpgme versions in gpg4win because gnupg is a "sub"-installer inside of gpg4win and it comes with its own gpgme. That gpgme is the release version but the one used by gpg4win's kleopatra is often a newer snapshot.

Here is the patch which will go into the next release

From f61a5ea4e0f6a80fd4b28ef0174bee77793cf070 Mon Sep 17 00:00:00 2001
From: Werner Koch <wk@gnupg.org>
Date: Tue, 22 Nov 2022 16:36:46 +0100
Subject: [PATCH] Fix an integer overflow in the CRL signature parser.

It turned out that the reason for the problem is the use of the --ignore-cert-with-oid option in gpgsm.conf.

We need to do this also for CHANGE REFERENCE DATA - however, there should be an extra option so that we can debug this despite of the redacting.

great hack

We should consider to break the Assuan API maybe we can do that without too many problems for the current use cases.

I don't understand the last two points: This is only about the three standard descriptors but how shall we supply more descriptors? At least in GPGME we definitely need more.

I just moved Phabricator to a new machine and created separte certificates for files.gnupg.net and dev.gnupg.org.

You need to handle them in a correct way. Just checking with gpg is
not enough because you don't know what has been signed. You need to
look at the signed data which gpg gives you by using the --output
option. And there you see only the signed data and not the extra
"aaa" you added after having signed the plaintext. It is not
different from adding stuff before the -----BEGIN PGP SIGNED ... line.

Actually I am not sure whether this is really a bug and that the fix is needed. What has been signed and verified is what gpg has seen and what --output has written. For example a line in the cleartext format may read "- From my " but what actually has been signed was "From my". If a line has been truncated --output will write only the truncated and thus verified data and not what was in the cleartext format.

The distinction between reader and card is not easy and PS/SC is also not helpful here. The user needs to resort to trial and error. With 2.3 things are much easier because we do not need to select the reader anymore.

Thanks. There should also be SPDX indentifiers everywhere.

AFAIK, Microsoft stated that the value of a HANDLE will always fit into a DWORD; i.e. only the lower 32 bits are used even on a 64 bit Windows.

Hi Vincent,

Meanwhile I have _some_ doubts that the v5 format is a good idea. It will introduce a lot of problems and thus a more lean way of replacing the fingerprint should be re-considered. Even if that means, we have to live with two kinds of fingerprints for a decade or so.

We won't do that. FWIW: We started to work on a 64 bit WIndows version of GnuPG.

Given that the OpenPGP WG practically decided to fork OpenPGP I don't see a reason why we should keep this bug open.

I can't see what we shall do here.

Will go into 2.3.9 and gpg4win 4.0.5

You are using a somewhat special setup and not what has been tested with gpg (i.e. putty). In particular Cygwin based tools do not interoperate well with non-Cygwin tools.

@jukivili: This has been released with 1.10.0 - shall we close this bug?

Shall we really backport this to 2.2 given that ECC for S/MIME is in most cases a smartcard thing?

Has been release quite some time ago (2.3.8 and earlier)

Will be released with 2.3.9