I confirmed that the patch above works with newer Gnuk (>= 1.2.16).

With newer Gnuk Token, following patch should work:

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 05e1f3977..439052f8c 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -5490,6 +5490,11 @@ do_auth (app_t app, ctrl_t ctrl, const char *keyidstr,
           exmode = 1;    /* Use extended length.  */
           le_value = app->app_local->keyattr[2].rsa.n_bits / 8;
         }
+      else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
+        {
+          exmode = -254; /* Command chaining with max. 254 bytes.  */
+          le_value = 0;
+        }
       else if (indatalen > 255)
         {
           if (!app->app_local->cardcap.ext_lc_le)

Here is my proposal patch:

diff --git a/random/random-drbg.c b/random/random-drbg.c
index 5a46fd92..f1cfe286 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -341,6 +341,9 @@ enum drbg_prefixes
  * Global variables
  ***************************************************************/

I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.

In computer, binary representation is used (generally), binary digits 0110 1110 (hex value 6e, 110) is rounded up to 1000 0000 (hex value 80, 128), when only one significant binary digit (bit) is required.
https://en.wikipedia.org/wiki/Rounding

Thanks for your explanation.

Patches applied and pushed. For the common/t-ssh-utils, I applied my fix for the use case with key on command line when FIPS mode is enabled (MD5 error is OK, in this case).

I just copied the value of 0xcafe2a8e and the name .note.fdo.integrity from Daiki's implementation. No other reason.

I think that good approach as of 2022 is:

libgpg-error 1.45 is out with the fix.

I think that it is OK to loop forever until we find a prime.

I don't know the exact procedure by FIPS, but just setting the least significant bit in the generation (after _gcry_mpi_randomize) can reduce the probability by half.

GPGME has its own system hooks to provide a (different) solution for portability (Windows and POSIX).

you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows?

SOCKET handle is UINT_PTR on Windows. It is u_int on original MinGW, it is UINT_PTR (and unsinged __int64_t) on MinGW-W64.

Last part is applied. Let me consider how to solve, for other parts.

Original MinGW and MinGW-w64 handle differently.
For MinGW-w64 on 64-bit machine, pid_t is 64-bit integer.
For original MinGW on 64-bit machine, pid_t is 32-bit integer.

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.