Fixed

We develop many versions of pinentry, but not the one for macOS. Therefore, we cannot help you. Please contact the developers of pinentry-mac (https://github.com/GPGTools/pinentry) or the homebrew maintainer of pinentry-mac (https://formulae.brew.sh/formula/pinentry-mac).

I've got a similar patch, but I'm not sure it's any better -- I'm adding EcDSA support for cards (via gnupg-pkcs11-scd) and with this patch I can sign subkeys and data.

Note the relationship to T4195, T4826, and T4766

Ready for testing

2. In the Certify dialog the "Advanced" expander lacks a focus indicator.

Hey Werner,

I installed zlib, looking at: https://aur.archlinux.org/packages/mingw-w64-zlib

I'm going test with 64-bit default lib32 with -m32 version, looking at: https://github.com/Jesseatgao/mingw-w64-multilib

For *.m4 scripts, I pushed changes to prefer gpgrt-config with *.pc files than *-config scripts (T5034).
Before the change, it was not coherent; gpgrt-config gpg-error is preferred to gpg-error-config (if available), but libassuan-config was used if available.
After the change, gpgrt-config is used to configure gpg-error and libassuan, etc.

For the migration, preferring gpgrt-config than *-config is better.
So, I decided to change *.m4 to do that.

The problem here is how large the data to be signed is. It is an issue of protocol design. The protocols are explained in openssh/PROTOCOL.certkeys and openssh/PROTOCOL. Unfortunately, it seems that it was designed with not much consideration for smartcard use case, so, data to be signed may be longer (than the capability of smartcard).

Sadly, it doesn't work for me. But thank you.

I managed to find a way to minimize the data (less than the one on Oct 25).
And it somehow works for me.

Another thing when we define a type which represents process.
For pid_t, MinGW-w64 has a bug: https://bugzilla.redhat.com/show_bug.cgi?id=1397787 (or https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/1456671365-21759-1-git-send-email-sw%40weilnetz.de/).
(1) GetCurrentProcessId always returns 32-bit (DWORD), so, it can be represented in 32-bit (although DWORD is unsigned).
(2) POSIX requires pid_t should be signed integer https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
(3) Original MinGW defines pid_t as int (in include/sys/type.h by _pid_t). (checked in mingwrt-5.4.2)

So what should I do now? Should I report it to OpenSSH team?

Yep. Closed now.

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