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:
My test coverage was not good (even if I daily use Curve25519 on Gnuk Token).
Your analysis is correct.
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.
Here is my observation.
The issue is the routines of regcomp, regexec, regerror and regfree are in C library and the sanitizer library replaces them (and it's not compatible for the use case of GnuPG).
Another possible change will be use of KEM interface for gpgsm.
Not high priority, but for long term code maintenance.
Thank you.
Clean up finished by rG681d75404300: gpg,agent: Clean up around using ECC KEM.
Tested by make check and decrypting tests/openpgp/samplemsgs/pqc-sample-*.enc.asc.
Pushed all changes needed. Actually, agent side too.
Clean up will be done.
Looking the FIPS 204 document, using the following functions (API) is good:
For prompting, I pushed a fix in rG45a11327f3bd: agent: Support the use case of composite PQC for prompting.
Thank you for testing.
Thank you for the concrete test case, it helps me.
NIST has an initial public draft for KEM: https://csrc.nist.gov/pubs/sp/800/227/ipd
It's in 1.11.1.
Included in 1.11.1.
(2) Update the documentation of default-cache-ttl zero value disabling caching.
I am going to do:
(1) Recover old behavior with max-cache-ttl = 0
(2) Update the documentation of default-cache-ttl zero value disabling caching.
It's not my intention. I didn't know the feature of disabling caching by max-cache-ttl to 0.
Well, it's a regression if a user intends so.
In libgcrypt/cipher/ecc-ecdsa.c, we have:
mpi_mulm (s, k_1, sum, ec->n); /* s = k^(-1)*(hash+(d*r)) mod n */