Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

I can replicate this. A quick strace with LC_MESSAGES=de_DE shows (gnupg master)

show English or Turkish strings?

Dan you please run something like

I am sorry, that I can't give it a high priority. See the discussion on the mailing list. I'll try my best, though.

@uwi: We removed the ciphersuite from the server and tested with 4.2.0 that you get an update notification now. Because of some caching you may need to

This is due to an update of the server providing the version info. The server (Apache) uses a smaller hash than the ECC key. This is allowed behaviour and was fixed in our TLS library in 2022; see T6059. However, the new library was released only early this year an. We will check whether we can tell our Apache to use a more correct hash algorithm.

What do you thing of storing the last WSAGetLAstError value also in the context and extend assuan_sock_get_flag to return this error value? The thing here is that I fear the mapped information is not enough to find the problem with the bind call.

Right, the first process is the gpg-connect-agent (via gpgconf). I used gpg just as an example. All processes use the same code to launch the agent.

Thinking again about this my hypothesis is:

In T7434#195318, @ikloecker wrote:

I'm wondering what happened (or why nothing happened) between the exit of gpg-agent[2816] at 10:11:12 and the start of gpg-agent[6492] at 10:12:00.

Also fixed for 2.4. Don't use the uninstaller on the command line, you should use the Windows method to do this.

Fixed with rG4c830b240c for gpd5 but after the release. Will fix it for 2.4 too.

Really. I do this for PGP files but I have not seen that elsewhere.

Not sure about gpg4win 4.2.0 but we had a bug in 4.3.0 which has been resolved with T6985

Or maybe not. I just did 0.11.0 (T7449) and will do more releases if there is demand for it or we have collected enough patches.

I don't really understand the problem. After all gpg-agent seems to be started using gpgconf --launch gpg-agent which should handle the locking properly.

In T7262#195642, @ametzler1 wrote:

I read this as bumping the version-number e.g. from 1.24.5 to 2.0.0 without e.g. bumping the soname or changing the api_version as specified in the .pc file. (FWIW I think that is a great plan.)

@ilf: Yes these message are emitted using log_info in 2.4.7 and 2.5.2. Thus they don't case a failure exit. I will silence them with --quiet in 2.5.3.

A workaround exists with the new option --ignore-crl-extensions.

Works for me in an NSIS installer. The VSD beta thing also works with copied conf files.

Kleo needs this only because it wants to directly talk to gpg-agent via Assuan. For example to get smartcard infos. What about delaying this part until you have received some data back from gpg or gpgsm? This makes sure that the agent has been started.

Let me guess: Kleopatra starts the agent using gpgconf --launch gpg-agent which in turn uses gpg-connect-agent to actually start the agent if needed. Kleopatra does not seem to wait for the launch to succeed and fires up gpg and gpgsm. They both wait for the gpg-agent to be started and both use the same locking strategy. However, this involves a pseudo random wait which should avoid deadlocks. See gnupg/common/dotlock.c:next_wait_interval