Backported to 2.2. Note that an updated libgcrypt is also required (for 2.2 and master)
Fri, Oct 23
Wed, Oct 21
All right, using the current master a Windows user with a Unicode name (e.g. Ⓐlfred E. Neumann) is now able to use gpg properly. Quite a lot of changes were required and backported to 2.2 will also be some work. More testing is of course required. Note that libassuan needs to be taken from Git until we have done a new release.
Tue, Oct 20
Mon, Oct 19
See also T5098 - I am sorry for this regression. We are working on a fix.
Which version of Gpg4win did you install, from where, and which OS version are you using? Why did you install gpg4win at a non-default location?
Sun, Oct 18
Wed, Oct 7
Thanks for the quick analysis.
Tue, Oct 6
We understand the problem, it's a regression from August. For T4083 we changed an internal function to better work with Windows UTF-16 filenames in preperation to at some point fully support UTF-16 and only use the wide character functions as system calls.
But that broke places where internally the local 8 bit encoding was still used.
I can reproduce this.
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)
Thu, Oct 1
@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?
Sep 28 2020
With all respect. Should I wait for a follow-up or I should consider this case as closed?
Sep 16 2020
Please note that:
- There is a single user accessing the socket dir (which is the same as the homedir).
- The socketdir (homedir) is not in a local directory. It is in another file system accessed via the SMB protocol, with a command such as:
gpg --homedir "//192.168.32.211/c$/gpghomedir" ...
From the '&ovl' I assume that the lock file has been opened for overlapped IO.
Please see an extract from MSDN for the LockFileEx function:
We need to figure out why the file locks seem not to work. gpg-agent processes whatch there own socket and terminate if that socket does not belong to them anymore.
Yes it is the windows version. It occurs both in Windows 10 and Windows Server 2016.
What I notice is that a gpg-agent is started, then after some time another one is started and the previous ends (presumably because it has lost the socket), etc. At any point in time, I can see only one agent instance running in the task manager, but with different process ids.
Sep 15 2020
I assume this is the Windows version. gpg uses a locking mechanism to avoid creating several gpg-agent processes. In the worst case this may take quite some time until one of the processes can get the lock. There is an exponential backoff scheme in use and I have not yet found a way to replicate the full deadlock you describe. It would be helpful if you could describe in more detail how you run into this case.
Sep 4 2020
So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?
Unfortunately you can't pass extra arguments.
Sep 3 2020
@bvieira You need to set pinentry-mode=loopback for gpg program used in git.
Sep 2 2020
I'm actually trying to do the following:
In the meantime you can use . I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.
Jul 30 2020
Pushed modified patch to master and 2.2.
Jul 29 2020
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.
Jul 20 2020
Any news on this?
Jul 17 2020
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 WSAStartup in assuan_sock_init (for Windows), the solution would be:
- Removal of call of WSAStartup 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.
Jul 16 2020
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.
Dec 5 2019
Sep 9 2019
Jul 16 2019
Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.