The minimum fix avoids changes needed, thus, a bit confusing as a whole.
Here are better changes:

Minimum fix is:

@jpalus You are right.

computed by ssh_signature_encoder_rsa, including additional 0, reach:

I applied the keyboxd part for SETEPHEMERAL command, as it doesn't break anything.

Here is an attempt to fix the client side:

Pushed: rG8b6de59ad880: agent: Raise GPG_ERR_BAD_SECKEY when p >= q for RSA key.

Pushed the change: rG533bcc265e9c: common:dotlock: Clean up for error/info/warning message.

While I pushed the change of libgcrypt, I'd like to apply following change to GnuPG.
This is more kind than GPG_ERR_BAD_PASSPHRASE by gcry_pk_testkey failure.

I retract my patch in T8171#215603

@m.eik gave us this link: https://github.com/ProtonMail/go-crypto/issues/184

It had already fixed in: rG55b5928099ba: dirmngr: Change the default keyserver.
And then in: rGa2f2523b99ff: Remove the default keyserver.

With same reason for T3852, I close this ticket.

GPGME has been divided into new GpgME, QGpgme, GpgMEpp, and GpgME-python.
And new QGpgme uses CMake now.

Pushed the change of gpgme: rM8b89678aed6d: Fix passphrase cancel handling.

Pushed the last change: rG2239f687bb14: scd:openpgp: UI improvement for use of PIN-entry.

It seems that pinentry-curses defaults to "OK".
(my branch for GTK-4, same.)

This is a bit larger change (of UI improvement):

I sent a patch to gcrypt-devel mailing list for the preparation of the change of RSA secret key checking.
If enabled, wrong RSA secret key (wrong means: under the Libre/OpenPGP specification) is rejected at import when gpg-agent calls gcry_pk_test_key.

I consider again about Ben's change. It could be simply support of the detection of the cancel situation where gpgme should return GPG_ERR_CANCELED (not related to single cancellation vs. whole cancellation).

I investigated the introduction of STATUS_CANCELED_BY_USER and GPGME_STATUS_CANCELED_BY_USER:
rG31e47dfad0f4: gpg: Add canceled status message.
rM35ca460019ea: Parse STATUS_CANCELED_BY_USER.

For OpenSSH, ssh-agent spec. defines p, q, and qInv.
FIPS has: FIPS 186-5 and SP 800-56Br2.

existing standards

CRT is used with GnuPG. In libgcrypt, pk_sign and pk_decrypt don't require P, Q, and U in a key (it's optional), but pk_test_key does.

@bernhard Thank you for the link.

I was wrong. gpg (scdaemon) needed to be fixed with more changes for the interaction with pinentry.

I pushed my patch for gpg, since it does not break anything, just allow empty passphrase input (to skip).
I also pushed my patch for gpgme. I believe that it's correct.

@ebo, I try to answer your question. As I wrote, the behavior of gpg implementations are different (for a reason). I'm not sure if you suggest the change of behavior of gpg 2.4.

I was too optimistic. GPGME is required the following change, too:

diff --git a/src/passphrase.c b/src/passphrase.c
index 140cd03a..d07afa91 100644
--- a/src/passphrase.c
+++ b/src/passphrase.c
@@ -114,6 +114,11 @@ _gpgme_passphrase_status_handler (void *priv, gpgme_status_code_t code,
     case GPGME_STATUS_CANCELED_BY_USER:
       return gpg_error (GPG_ERR_CANCELED);

I'd propose applying the patch of mine above to gpg, and letting us suggest users to input empty pass phrase to skip (instead of cancelling).
This could be a minimum change (only gpg). Or else, gpgme needs to be changed to ignore CANCEL status and to handle complex cases; I think that it's not easy change.

Possibly, it was the same cause as T8052 (the bug in libgpg-error spawning a process).

I looked at sm/keydb.c:keydb_set_ephemeral function. It says:

How did you configure? If possible, please show us the configure options when you built.
Did it work in older version(s) of libgpg-error?

It seemed that the reporter (also) claimed that a git repo could be weak/vulnerable when X.509 signature (with a relevant curve key) is used to validate the commit.

For the record (to show we don't hide a problem), I add some information.

It should be solved by the upstream (libtool, gnulib, and possibly autoconf/automake). The solution would be refactoring AC_PROG_LD and AC_LIB_PROG_LD factoring out common things like handling of use of GNU LD.

The reporter informed us that the possible DoS has CVE number assigned:
CVE-2025-69913