Pushed the change.

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

@ametzler1 Thanks a lot for your help.

Sorry, it looks like no problem.

Implications are... you won't be possible to use new protocols introduced by newer OpenSSH:

Thank you for the bug report and your suggestion.

In my cases (tested with 9.1), here are the length of data to be signed by ssh-agent (emulation by gpg-agent).

• 164 bytes: Both features disabled by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com -o PubkeyAuthentication=unbound
• 192 bytes: Unbound only by: ssh -o PubkeyAuthentication=unbound
• 298 bytes: No Post Quantum only by: ssh -o KexAlgorithms=-sntrup761x25519-sha512@openssh.com
• 330 bytes: Both features enabled (no options)

I tested with openssh 9.1. When I add -o PubkeyAuthentication=unbound, I can make the length of data smaller.

Please use gpgme.pc to configure your build. Your options are:
(1) With Autoconf:
(1-1) Use pkg.m4 and PKG_CHECK_MODULES (which uses pkg-config to access gpgme.pc)
(1-2) Use gpgme.m4 and AM_PATH_GPGME (which uses gpgrt-config to access gpgme.pc)
(2) Or... use pkg-config to access gpgme.pc.

On Windows, closing/inheriting handles is different to POSIX.
https://devblogs.microsoft.com/oldnewthing/20111216-00/?p=8873
https://devblogs.microsoft.com/oldnewthing/20130426-00/?p=4543
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexw
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-initializeprocthreadattributelist
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-deleteprocthreadattributelist

I put rCc34c9e70055e: fips: Mark AES key wrapping as approved. under this task, so that it can be referred in the release note.

Let me describe the changes recorded in this task.

I'm going to use gnupg_process_* prefix for the functions.

I updated gpgme.m4 to include configuration of GPGRT_CONFIG.
Using this new gpgme.m4, it should work.
Using this new gpgme.m4 plus old gpg-error.m4, checking GPGRT_CONFIG is duplicated.
Using this new gpgme.m4 plus new gpg-error.me, no problem.

I overlooked the use case of gpgme programming not using libgpg-error. This use case should be supported.

Last two points are for future changes of assuan internal; For the case of controlling fds in detail, it is possible to use spawn callback controlling fds by the routine and let no-touching (inherit) by the spawn function.

Evaluating again, I'd like to change spawn functions like this one in libgpg-error:

Examining again, I realized that the current spawn API (not published yet, only available in libgpg-error master) is not that useful in general (or difficult to use), while it works somehow.

Now, we implemented fd passing on Windows in libassuan.
Note that the process identifier (represented by DWORD) and handle for a process (represented by HANDLE) are different things.

Here is the change of GnuPG to use new spawn functions from libgpg-error:

Merged PIPE connection part into master.

For the spawn_cb, I reconsider. Having three calls complicates use, and it is actually not needed. In the case of pthread_atfork, it is needed, because fork may be used deeply in some functions. In our use cases of spawn function, prepare part of the callback can be called before calling spawn, and parent part of the callback can be called after calling spawn.

I decide use of pid_t, as there are different semantics between POSIX and Windows, *and* there is a problem of MinGW-w64. I introduce gpgrt_process_t, instead.

I updated *.m4 scripts in gogol:

I installed zlib, looking at: https://aur.archlinux.org/packages/mingw-w64-zlib

I'm going test with 64-bit default lib32 with -m32 version, looking at: https://github.com/Jesseatgao/mingw-w64-multilib