gpgrt 1.57 will come with gpgrt_fconcat. This can be used to get the sysconfig in a portable way:

@werner For rCd5e3cbfd , my mingw (GCC version 14) complains about the function-return-type difference of the prototype with GetProcAddress.

Scute fixed in rSc3dc9c581631: w32: Use CSIDL_COMMON_APPDATA if available.

Okay, forward porting that patch is the easiest solution. Actually this is not enough: Users of Libgcrypt also need to make sure that the new sysconfig dir has the right permissions. That's a part for the installer and concrete ACLs may differ.

I examined the code of gnupg_sysconfdir in gnupg/common/homedir.c, if we could factor out things to gpgrt, so that something like gpgrt_fconcat with GPGRT_SYSCONFDIR can be implemented.

For GnuPG, applied the change to master: rG57affc4e98ab: common,agent,dirmngr,kbx:w32: Synchronous spawning daemon process.

I checked the code under gnupg/dirmngr. Those are no harm.

I think this is correct even on Unix in case someone really uses /usr/local/etc (which I consider problematic). But for Windows we need to determine this at runtime.

For gpgrt/argparse this could be an option (to remove hard-coded /etc):

Fixed in 1.56.

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 looked at it but we probably need to rework/update the entire libtool stuff which has a high regression risk. Thus I give this bug a low priority because it is not a functional bug.

doc/HACKING says it's OK to use variadic arg macros (from C99 features).
If it's OK, this patch can fix the initialization (which silences GCC 15 warnings):

Note that 1.53 was released today which fixes a small regression:

In case of build problems related to a failed test you may want to apply rEb6df311368133df90c3bf338fbf5c90bd8d950f8.

Fixed in: rE0f4fe2edf5e5: spawn: Care about closefrom/close call is interrupted.

@werner I read the code of gpgme/src/posix-io.c. I understand the two points:

• For the correctness sake, the possible interrupted closefrom should be handled.
• we can share the code with closefrom case and non-closefrom case.

@gniibe: Please see gpgme/src/posix-io.c where we have this:

Thank you for your report.

Fixed in rA69069bc63e6b: Remove an declaration for an unused function.

Hm, this might also be relevant in GnuPG's codebase in common/exechelp-posix.c, which contains a copy of the same code (licensed differently).

This problem has gone in libgpg-error 1.51, since the implementation doesn't use environ any more.

Fixed in 1.51, by introducing gpgrt_spawn_actions_set_env_rev, which assumes utf-8 encoding.

Fixed in 1.51.

Fixed in 1.51.

Thanks. Fixed in: rEd14c69a7f256: Avoid use of 'nullptr' for an identifier.

The C comittee is getting more an more absurd by adding new keywords. Breaking software for fun and funding. Workaround should be easy: Don't use the C23 option.

With the change, T7169 is fixed (by side-effect).

Pushed the change: rE1860f6407f83: spawn: Add new function to modify environment.

Thanks for opening a bug report. This is better for our workflow.

Replacing gpgrt_spawn_actions_set_environ by gpgrt_spawn_actions_set_envchange is not good, as it's exported and already used.

Here is my attempt: