@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_.

I have now seen instances where 1, 2, or 3 processes hang.

In T7656#201529, @ikloecker wrote:

In T7656#201519, @TobiasFella wrote:

Do I understand correctly that this bug is then automatically done/fixed?

It depends on how the version comparison works. We may have to change the code to extract the version number (e.g. 5.0.0) from the version string.

I forgot to mention that gpgrt has an API to compare version numbers in the same way gpgconf and all gnupg components do it; this should be somewhat similar to sort -V

BTW, if you append a beta string the thing works as well. Thus with an development version for 4.4.2 we would get a 'newer' state:

The version file is locally cached and updated from time to time unless that feature is disabled.
An update can be forced using

Re: pipe2: In gpgme_io_pipe we set FD_CLOEXEC only for one end of the pipe. Thus simply using pipe2 would change the behaviour.

By the way, Kleopatra uses GpgME::SwdbResult::query() which I expect to do what you propose.

First, gpgconf doesn't help with parsing a version string like gpg4win-5.0.0-beta190 which is what I was talking about. Once we have extracted "gpg4win" and "5.0.0" we could use gpgconf. ...if it worked as documented in the man page. I don't understand this:

$ gpgconf --query-swdb gpg4win 4.3.0
gpg4win:4.3.0:-::32849:::::::

This is all done by gpgconf like here:

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).

There is FD_CLOFORK on Solaris 11.4 as well. It is a part of POSIX-1.2024, but who knows how long until that becomes common.

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.

In T4836#132493, @aheinecke wrote:

Thank you for the detailed report.

We recently had a similar problem with S/MIME Mails. T4543 I think that we can apply the same fix we did for S/MIME also for OpenPGP. So I give this high priority as I think that this can be easily fixed and is a big problem in mixed environments.

In T7656#201519, @TobiasFella wrote:

Do I understand correctly that this bug is then automatically done/fixed?

I do not think that this is the only place where such an issue occurs. Maybe we should make the documentation clearer about context key reuse. But the context is specifically designed to cache information about a key, so as to avoid memory overhead. I learned early on that its best for each new operation to use a new context. A context is basically an instance of gpg or gpgsm. So you start one process, ask it for a keylist, keep the process running, start another process, modify the key database, and then ask the first process again about his worldview. Either the first process is a bit confused because it has read data and then that data changed (what happens here) or it has no idea about the change since it was efficient and only read the database once. But here in this example you should be able to reproduce this also by making any other modifications to the key, adding other subkeys, userids etc. That GPGME even notices the secret key is more of a side effect of how the programming works because the GPGME gpg process will ask the gpg-agent (so a third process).

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

Thanks, that was the only issue building there.

Note: The Kleopatra in upcoming versions of Gpg4win 5 will have AboutData::version set to gpg4win-5.0.0 (or gpg4win-5.0.0-beta190 for beta versions). See T7666: Kleopatra: Rework versioning.

This should compare the gpg4win version number:

I updated the github issue. The suggested change seems to have had no effect.

Thank you @alexk

I made a comment on github.

Please re-open if you find other Cygwin related build problems.

You know that Cygwin is not supported but if that is the only place it should not arm to fix it.

Thanks for the quick fix. I feel a bit silly for not notcing that macro myself...

Fixed in all branches but there is no potential for exploiting. See also gnupg-devel@ ML.

This should do the trick (master) but have not yet tested it:

Fixed. Thanks for the report!

Thank you.

Maybe related:

In T7658#201260, @TobiasFella wrote:

That screenshot is for kleopatra crashing, not related to okular.

That screenshot is for kleopatra crashing, not related to okular.

The problem here is that the version number in kleopatra is still 4.0.0-something, which is then compared to 4.4.0.

In T7627#200387, @werner wrote:

We won't apply any fixes to the cpp, QT, or Python language bindings in the 1.24 branch. The Qt branch has been factored out to the gpgmeqt project on request from the KDE folks. And yes, we should add projects (tags) for gpgmepp and gpgmeqt.

Spent some time discovering and unfortunately it's Windows's bug in loopback interface.
I wrote a test demo (blocking mode) to exchange data and watched their packets, found that network stack would drop packets when congestion control algorithm is set to BBR2. It seems the second data exchange was broken.

Problem noted in T7166

Patch applied.

I can confirm this. Here is the build error:

make[2]: Entering directory '/home/collinfunk/libgcrypt-1.11.1/cipher'
`echo /bin/bash ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..  -I../src -I../src -I../mpi -I../mpi  -I/home/collinfunk/tmp/include -g -O2 -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -O2 -march=rv64imafdcv -mstrict-align -c rijndael-vp-riscv.c | sed -e 's/-fsanitize[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' -e 's/-fprofile[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' -e 's/-fcoverage[=,\-][=,a-z,A-Z,0-9,\,,\-]*//g' `
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I../mpi -I../mpi -I/home/collinfunk/tmp/include -g -O2 -fvisibility=hidden -fno-delete-null-pointer-checks -Wall -O2 -march=rv64imafdcv -mstrict-align -c rijndael-vp-riscv.c  -fPIC -DPIC -o .libs/rijndael-vp-riscv.o
rijndael-vp-riscv.c:58:10: fatal error: simd-common-riscv.h: No such file or directory
   58 | #include "simd-common-riscv.h"
      |          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:1730: rijndael-vp-riscv.lo] Error 1

Patch here: https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005854.html

Also pushed to 1.11

Using the primary key for ssh was not intended and thus not tested. I have not yet found the time too look closer at your report. Just one remark:

Thank you again for the reactivity! Applied, everything seems to work just fine.

For prompting, I pushed a fix in rG45a11327f3bd: agent: Support the use case of composite PQC for prompting.
Thank you for testing.

Thanks! With that patch applied, decryption works fine.

Thank you for the concrete test case, it helps me.

looks good to me on gpg4win-5.0.0-beta190@win10

I think we have another report on this in the tracker. The problem is indeed the ugly Windows time functions to print a string. Let me only remind that until a few years, Windows had the opinion that Germany uses the Westeuropäische Zeit like Portugal or the UK.

That is quite possible because we do not have a test system for RISC-V and the make release tarbegt is not abale to verify this.

In T7620#200845, @Saturneric wrote:

I think it would be much better if GnuPG automatically performed a key listing immediately after key generation when a smartcard is involved. This would allow GnuPG to detect the presence of the subkey on the card right away, rather than leaving it marked as a stub until the user manually lists keys.

I see that you generated the secret encryption subkey with backup. This means that the secret subkey is generated on your computer, then copied to the card, and then deleted from your computer. The deletion is the reason why the subkey is marked as stub. Only after listing the keys on the card gpg notices that the secret key is actually on the card.