But we have the same problems on Unix as described by T7699. (funny, the other bug mentioned above has 76 reversed)

That is not Windows specific. They should end up in %GNUPGHOME%/kleopatra/

What about including the output of

secp256k1 is an --expert option and not supported by other *PGP
implementations. We should actually hide this thing even more and not
even display it with --expert. Thus do no expect an immediate 2.5.9
release to fix this issue.

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

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?

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

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.

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?

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.

Just to be clear: You originally installed it as a portable applications and then you also installed a new version in the standard way?

Can you figure out who started gpg-connect-agent? Note that it is also used by gpgconf to reload, kill, or launch daemons.

I stumbled into this problems myself yesterday. Time for a new release.

We will keep the 1.24 branch for bug fixing. Do you really have a problem with gpgme 2.0? Ist that due to factoring out the c++ and qt bindings? That was actually a long standing request from the KDE community so that they can use their cmake stuff.

I updated the version database. We now have entries for "gpg4win", "gpd", and "vsd"

I see, I had rfc2440 in mind which says:

By convention, it includes  an RFC 822 mail name, but there are no restrictions on its content.

thus 4880 refined it a bit. But in practice it is not the same because it is utf8 and not punycode or whatever. let's close this bug because they way it is used will work with all mail clients.

Let's have a look at the spec (rfc2822 3.4):

address         =       mailbox / group

We should also add a check that INDATALEN is > 15 to make the function robust against bad args.