gpg4win 3.1 has no full Unicode support. You may try to install the new GnuPG 2.3 version on top of gpg4win to fix this problem or wait until we have releases gpg4win 4 which will come with GnuPG 2.3.

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

Example from gpg.c:

ARGPARSE_s_n (oQuiet,	  "quiet",   N_("be somewhat more quiet")),
[...]
ARGPARSE_s_n (oNoGreeting, "no-greeting", "@"),

The quiet option has a human readable description, but the no-greeting option does not have one. Consequently, gpgconf --list-options gpg gives the following result:

[...]
quiet:0:0:be somewhat more quiet:0:0::::
no-greeting:0:3::0:0::::1
[...]

For comparison, on an English Linux system the options also look wrong, i.e. all options that are problematic in the German translation are "raw" option names enclosed in double quotes. It seems that the untranslated description of the options is already missing.

Btw this only occurs for some options:

That it. Things works nicely for me. Won't be backported to 2.2 because this introduces minor changes in the behaviour.

Well, this is a pure Windows bug. It easily shows up when running dozens of gpgsm processes each importing a different certificate (e.g. using Kleopatra's current importer, which spawns one process per cert). The only possible fix is to close all files before starting a long running operation *and* before locking the files.

@rjh reported a problem with keyboxd from the current 2.3 beta on the ML. This is also a locking problem and _might_ be related to this bug.

Reopening this as I have seen such hangs multiple times during testing. When importing multiple keys with Kleopatra at once this can be reproduced sometimes.

Thanks for your answers. If you see another problem with kleopatra, please test the latest Kleopatra version which we will release the next days.

1. I created another handful of key pairs and tested around. However, I could not recreate the problem now. I can store the secret key in Kleopatra, but the file differs from the backup key. It seems to be a stub indeed. And even if I want to perform an operation directly in Kleopatra, the smartcard is requested.

Why do you think you can still export more than a stub key?

The listing shows that the private keys are stored on a card ("sec>", "ssb>"). Why do you think you can still export more than a stub key? If I export a test key (just the primary key in this case) and run "gpg --show-keys" on the exported file I get the expected "sec>" marker. Looking with --list-packets at it we get:

The exact commands given and the output. Adding -v is always helpful.

Hi, I'm the user that reported this bug.

On Thu, 7 Jan 2021 09:56, bernhard (Bernhard Reiter) said:

The user reported to

Please describe exactly what you did so that we can replicate this.

I wrote https://github.com/rupor-github/win-gpg-agent to simplify usage on Windows until this issue is resolved - it handles various edge cases on Windows.

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

It was a bunch or work and we are still not able to pass Unicode strings on the command line. Will eventually be done. At least people in Asia can now use their regular Windows account with gpg.

Thanks Werner! Seems like an important step!

No, overlapped I/O is not used. OVL is just a zeroed out memory area and thus hHandle is NULL. Errors are of course checked.

Backported to 2.2. Note that an updated libgcrypt is also required (for 2.2 and master)

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.

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?

Thanks for the quick analysis.

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.

Observation:
The umlaut is displayed incorrectly on the command line (cmd.app) when the keybox file is created.
(This may or may not be relevant.)

@werner can you confirm if the environment I provided will work with OpenSSH support fully implemented?

With all respect. Should I wait for a follow-up or I should consider this case as closed?

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.

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.

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.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

I'm actually trying to do the following:

In the meantime you can use [0]. 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.

Pushed modified patch to master and 2.2.

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.

Any news on this?

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.

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

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.

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.

In T4932#134540, @aheinecke wrote:

If you have -g / -Og could you please provide a backtrace?

If you have -g / -Og could you please provide a backtrace?

Attaching the actual program

3.1.11

Please let us know which version of Gpg4win you are using.