Reading the commit log message in rG6dc3846d7819: sm: Support creation of EdDSA certificates.
I created a file to keygen.

Key-Type: ECDSA
Key-Length: 1024
Key-Grip: 0286DCA85E771F64AB9FD9C89717369524D55471
Key-Usage: sign,encrypt
Hash-Algo: sha384
Serial: random
Name-DN: CN=dummy test nistp384

I updated the branch.

I think that modifying gnupg_remove is a bit risky because it's used in many places.
I'd rather introduce new function for Windows; gnupg_w32_delete_file for this particular purpose.
Factoring out wait_when_sharing_violation function from gnupg_rename_file.

Here is a possible fix:

This is current work of mine:

I can't find any causes of slowness in keyboxd initialization. I think that there is a situation where it simply takes time on Windows.

@ametzler1 Thank you.

test -a is not a POSIX construct, I intentionally avoided it.

@ametzler1 Thank you for your report.
I modified a bit (not using && between two test but using -a for a single test command), and pushed the change:
rP121494245f49: build: Allow build with fltk 1.4.

@m.eik Could you please enable debug option for gpg-agent and get the log output for the crash?

I fixed the problem (which I identified above) in gniibe/t7759 branch. There might be other causes/problems for the particular symptom, so, I don't know the fix resolves the symptom or not, though. Anyhow, I believe that this is an improvement.

Thank you for the report.

Similar situation could happen with gpgsm + gpg-agent, when gpg-agent is invoked by gpgsm.
(1) No gpg-agent.
(2) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(3) In gpgsm_keylist, it makes sure gpg-agent is available by GETINFO agent-check, using gpgsm_assuan_simple_command.
(4) In the server side, it tries to connect gpg-agent, invokes gpg-agent, and connect to the agent again.
(5) On Windows, it may takes time to invoke gpg-agent. And it may try to connect multiple times. Each trial may generate debug messages.
(6) When it takes too much time, the debug messages are too much. It may fill the pipe.
(7) And it blocks at log_string in my_libassuan_log_handler.
(8) ... it hangs.

Hypothetical scenario (gpgsm --server + dirmngr):
(0) It may hang when much debug messages are generated by libassuan to the pipe of --logger (diag_cb).
(1) In gpgme, by engine-gpgsm, gpgsm is invoked with --logger.
(2) If it's the case of standard gpgme interactions which uses gpgsm_io_event, no problem. Because the data on diag_cb is consumed well.
(3) In case of gpgsm_encrypt (or other commands), it uses gpgsm_assuan_simple_command which does not consume the data on diag_cb pipe at all.
(4) In particular, in set_recipients, gpgsm_assuan_simple_command is called by the number of recipients times.
(5) IIUC, in the server side, to handle RECIPIENT command, dirmngr is used by the call chain of:

• cmd_recipient
• gpgsm_add_to_certlist
• gpgsm_validate_chain...
• gpgsm_dirmngr_isvalid

(6) In gpgsm_dirmngr_isvalid function, libassuan is used as client side, it generates debug messages.
(7) When there are many recipients, the debug message may be big enough to fill the pipe.
(8) When pipe is filled, it blocks at log_string in my_libassuan_log_handler, waiting the data in pipe is consumed.
(9) ... it hangs.

The patch above is wrong for if (!rc) last_err = rc;, the condition should be (rc).

It's in master (to be 1.12), then, it's backported to 1.11.2, which is confirmed build well.
So, closing.

Applied the change above.

I realized that I enbugged in rG5efabec21883: gpg:ecc: Use the common function of gnupg_get_ecc_params..
It has been regression since 2.5.9.

Pushed the changes in {gniibe/synch-spawn} branch.
It consists of three commits:

• rGb8b8afc5cf6f: build: Require libgpg-error 1.56 or newer.
• rG15b8bc7495db: w32: Synchronous spawning gpg-agent/dirmngr/keyboxd.
• rG6bd6826aa6ff: common:w32: Care about the NUL device for start_new_service.

In T7642#203189, @gniibe wrote:

I wonder about GCC 15 preparation for the release. If it's good to have, three patches are needed to apply:

I pushed the longlong patch: rCb61a7661d017: mpi: Provide the function prototype of __udiv_qrnnd.

IIUC, it's actually binutils version dependency (instead of GCC 15), perhaps.

I wonder about GCC 15 preparation for the release. If it's good to have, three patches are needed to apply:

• Cherry-picking rCd5fb7cd9b351: Mark nonstring use cases with __nonstring__ attribute.
  • strictly speaking, this adds a macro, which is considered an API change
• Cherry-picking rCf06e90f4137a: cipher:ecc: Silence GCC 15 warning.
• Apply changes of T7721: libgcrypt build-error with gcc-15 on powerpc and alpha

I figured out that .machine "any" is needed with GCC 15.

For Alpha (hppa, and sparc), IIUC, following patch may help:

For PowerISA 3.00 Instructions issue, following patch may help:

Here is a patch.

diff --git a/agent/divert-scd.c b/agent/divert-scd.c
index 1e5de4671..bb42dd3b4 100644
--- a/agent/divert-scd.c
+++ b/agent/divert-scd.c
@@ -517,6 +517,9 @@ agent_card_ecc_kem (ctrl_t ctrl, const unsigned char *ecc_ct,

Fixed with new GPGRT_PROCESS_STDIO_NUL flag.

Pushed the changes:

• Inheriting HANDLEs has been not working accurately
  • Before the fix, all HANDLEs were inherited
  • Only specified HANDLEs are inherited by: rE0b01950237ab: w32:spawn: Fix inheriting HANDLEs.
• HANDLEs by w32_open_null were leaked
  • fixed by: rEf28bf71b86ba: w32:spawn: Fix resource leaks for HANDLEs by w32_open_null.

T7723 fix by rE311fb769d1dd: w32:spawn: New flag GPGRT_PROCESS_STDIO_NUL.

Before implementing this feature, it's better to fix T7723: gpgrt:w32: Fix for inheriting stdin/stdout/stderr with "NUL", and do some clean up.

If we will fix gpgconf using GPGRT_PROCESS_STDIO_NUL, we will need to fix gpg-connect-agent to see if it's NUL or not.

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.