Thu, Jul 30
Pushed modified patch to master and 2.2.
Wed, Jul 29
That patch fixes the build problem I got into today when trying to build 2.3 for windows. So 👍 from me and please commit the patch as it is already required when assuan and gpgrt config no longer emit ws2_32 in their pgk-config --libs line.
I just saw that there is related discussion and a patch for this in T4994 so I will close again here.
This change broke for me the compilation of GPGME which I fixed with: 52f930c1ed7eee6336a41598c90ef3605b7ed02b I found that fix there OK because GPGME explicitly uses ws2_32.
Linking $(NETLIB) is required when the executable uses WSAStartup.
Mon, Jul 20
Any news on this?
Fri, Jul 17
I just learned that WSAStartup can be called multiple times. So, it doesn't cause any erroneous behavior which I had been afraid of.
Thanks for looking into this. However, I do not understand the problem behind it. Is it the need to link against the socket lib? 10 or 15 years ago things were more complicated because two TCP stacks were in use and you could use the modern one only if a certain service pack or Explorer version was installed. That might be the reasons for some of the peculiarities we have in the code.
Given the situation we have call of WAStartup in assuan_sock_init (for Windows), the solution would be:
- Removal of call of WAStartup in _init_common_subsystems
- Even though it is not needed for POSIX system and it is only needed to call WAStartup on Windows, calling assuan_sock_init from each application (including gpg, gpgsm, dirmngr/dirmngr-client, and tools/* which uses libassuan), would be the solution (not perfect one, though, because it allocates sock_ctx)
Sorry, I was confused by assuan_socket_ API and assuan_sock_ API.
Thu, Jul 16
No info received
I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.
Here are the fixes:
diff --git a/common/init.c b/common/init.c index 073c5cd8a..dbdf40527 100644 --- a/common/init.c +++ b/common/init.c @@ -161,17 +161,6 @@ _init_common_subsystems (gpg_err_source_t errsource, int *argcp, char ***argvp) /* Try to auto set the character set. */ set_native_charset (NULL);
Call of WSAStartup in dirmngr/http.c is no problem, as we define HTTP_NO_WSASTARTUP.
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
May 29 2020
May 11 2020
I see no reason to not allow decryption of an entire folder recursively. The user knows what they are doing by right-clicking a folder instead of a file. You can show a progress dialog with a cancel button.
May 8 2020
Right. GpgEX is in serious need of polishing. I'm not sure if I'm in favor of processing all files recursively. But then the decrypt option should not even be shown.
If you have -g / -Og could you please provide a backtrace?
May 1 2020
Attaching the actual program
Apr 17 2020
Please let us know which version of Gpg4win you are using.
Mar 12 2020
Mar 9 2020
Added variable value
set language LANGUAGE=en_US
I launched the Kleopatra again. I did not notice any changes.
Thanks for your report. Yes this is sadly a known issue. Our backend system has it's own localization that uses the system language and does not care about the Kleopatra configuration.
Feb 25 2020
Feb 18 2020
With the fix of T4623, this bug is now fixed.
Fixed in master, using Libs.private support.
Dec 12 2019
Although I don't use the ssh client on Windows I had to integrate the Windows ssh server into our release process (GlobalSign sent us a Windows-only token, for the new cert and so we can't anymore use osslsigncode). The ssh server is really stable and so it makes a lot of sense to better integrate our ssh-agent into Windows.