Fri, Oct 23
Backported to 2.2. Note that an updated libgcrypt is also required (for 2.2 and master)
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.