Here is an experimental change to support the feature.

I'm testing the following patch with experimental change of libgpg-error.

In libgpg-error, we have: rE65114f24e13f: w32: More changes to the extended length path handling.

Fixed in 2.5.8.

secp256k1 failure:
https://lists.gnupg.org/pipermail/gnupg-users/2025-June/067731.html

Done by: rM8caa7cc517eb: Use sysconf as a fallback mechanism in the initialization.

OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

In the log, we can observe duplicated lines generated by
https://dev.gnupg.org/source/gpgme/browse/master/src/posix-io.c$545
Example is like:

2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1
2025-05-19 20:16:35 gpgme[21970.55d7]   _gpgme_io_spawn: check: fd[0] = 0x1c -> 0x1

Done in 1.11.1.

Done in 1.11.1.

Done in 1.11.1.

Reading https://openssl-library.org/files/blog/Request_to_Extend_IETF_WGLC_for_PQ_Key_Specifications.pdf ,
seed (with "S") is included in the private-key.

The commit rC23543b6c1497: Add mldsa_compute_keygrip and let private-key include "p". works well for me.

To support Dilithium, we need to extend data handling of libgcrypt.
I propose following changes:

• internal flag of PUBKEY_FLAG_BYTE_STRING to ask opaque MPI for data to be signed/verified.
• The format of data as: (data(raw)[(flags no-prefix)](value ...)[(label ...)][(random-override ...)]): message, context, and random. Optional no-prefix flag to ask specific way of signing, controlling the internal, for Known Answer Tests (siggen).

My test coverage was not good (even if I daily use Curve25519 on Gnuk Token).
Your analysis is correct.

OK, fixed in rG27e6622322b5: scd: Take care of possible buffer overflow in do_auth.

The problem was: In scdaemon, PKSIGN with OPENPGP.3 didn't work well for Ed25519 (done by do_auth function in app-openpgp.c), when --hash=sha512 (not SHA1).

I located the bug in scdaemon.

@sj98ta
Does cri-o invokes processes (other than the ones of gpgme) by its threads?

@sj98ta Please let us know if cri-o invokes other processes (except the ones by gpgme) or not.
If cri-o invokes other processes (by other threads), my theory matters; With the interference by other processes holding pipe file descriptors, gpgme keeps polling pipe file descriptors.

Pushed the change: rG16ee68259d1d: gpg,regexp: Use -DREGEXP_PREFIX=gnupg_.

Here is a hypothetical application which may have similar problem.
(1) It is a multi threaded application using gpgme, forking another process (possibly, exec).
(2) One of threads invokes gpgme_new, gpgme_op_import and gpg_op_verify.
(3) When the control goes to gpgme_op_* then gpgme_io_spawn by a thread A, another thread B forks a process.
(3-1) While the thread A is polling pipe I/O, forked process holds pipe file descriptors too.
(3-2) Until the forked process exists, pipe I/O polling by the thread A continues (because pipe's other end is still active).

I don't know if it is related to this particular case, but I found a possible race condition in _gpgme_io_pipe.
Between pipe and fcntl with FD_CLOEXEC, another thread may fork a process which keeps running.
It would be good to use pipe2 here:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pipe.html

Another possible cause is... gpgme uses closefrom in GNU C library, if available. if it doesn't work well, it would be possible invoked gpg keeps waiting its input.