In case of problems with token based cv25519 key, please update to 2.5.8.

OK. I'll add a code for setting the fallback value in _gpgme_io_subsystem_init and use it from get_max_fds.

iirc we introduced sysconf (_SC_OPEN_MAX) for non-linux platforms and that fixed real world problems. What about getting this value at module initialization time and keep on using it as a fallback?

For issues of get_max_fds, I created a sub task, although it seems not the direct cause of this particular problem.

I test following test program (gcc -o t-gmf t-gmf.c) on Debian machine of S390x.

We decided in T7579: Kleopatra: improve menu items to remove this action. Users will instead have to mark certificates they want to update and use the Update Certificates action in the "Certificates" menu.

After several gpg4win-5 betas be can set this task to resolved.

I claim this resolved given several gpg4win-5 betas.

I claim this resolved given that we had several gpg4win-5 betas and no reported problems was related to this.

The actual project we had in mind for this was more or less canceled and thus I re-prioritize this task.

Reminder mostly to self: This is about the KDF parameters. In the light of PQC composite algorithms we may want to also prepare for PQC required stuff.

There should be a workaround by using

This was release with 2.5.7.

Funny old bug which shows up only if you don't have any keyserver configured. Note the FIXME in the commit ;-)

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.

Can be tested with next VSD 3.3.x build.

The only time I succeded in reproducing this was when I broke my gnupg setup and got a mix between gpg from one version and gpg-agent from another.

The question is whether any part of Qt/KF6/MTP forks another process and does not do it correctly. For example it is required that the child figures out the fds to close and then closes them and does not rely here on the parent.

For each part that needs to be reencrypted I create a QGpgME Encrypt Job

Do you start other process while this context is in use? If you do a fork, you need to make sure that all file descriptors are closed. How is that done?

Interesing part of the logs:

merged