Forgot to mention one thing: after changing my user folder directory I lost all my Outlook contacts. I was able to recover them... make sure you have a backup before attempting this!

I just had the same issue as hurui200320. My user name contains a "ç" and Kleopatra did not start. The Windows event logger reported a crash in libstdc++-6.dll. This was with gpg4win-3.1.16. Installing gnupg 2.3.1 did not change anything.

It is a matter of the used font. 2.2.29 will fix this problem.

Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.

I did some test on Windows 10 using gnupg 2.2 with this patch and things work.

For testing ion Windows 10 you need to switch to "Legacy Console" and reboot.

I think that a patch like following is needed:

diff --git a/common/ttyio.c b/common/ttyio.c
index c385700de..55468bdf0 100644
--- a/common/ttyio.c
+++ b/common/ttyio.c
@@ -236,7 +236,21 @@ w32_write_console (const char *string)
   n = wcslen (wstring);

When console font is not a Unicode font, it seems that the WriteConsoleW function may return ERROR_GEN_FAILURE.

Hello Mr. Koch,

Please run

Hello Mr. Koch,

Are you using Powershell or another non-standard shell? Which windows version are you using? Do you use default-key in gpg.conf? Do you have a smartcard inserted?

With sqlite3 using -static-libgcc, I confirmed that GnuPG and its friends are built well with newer mingw on bullseye. And I lightly tested GnuPG on Windows.

Ah, I realized that the build for sqlite3 in Speedo has a patch using -static-libgcc.

We use libgcc_s_sjlj-1.dll only for for gpg4win's C++ code which is gpgme's c++ binding and the Qt stuff.

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

(I disabled the account of this boor)

I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.

I wonder if PCSC_SHARE_SHARED is related or not.

Given that we don't yet support TPM for Windows you should go ahead and apply this patch. tpm should also be removed from the list of components.

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.