Gpg4win problems for Windows Users with some non-ASCII account names
Testing, HighPublic


As reported in
a pubkey could not be imported and a new keypair could not be created with Gpg4win 3.1.13
it worked with 3.1.10 before.

The problem is a non-ASCII character in the user name of the windows account.

How to reproduce:

  • Install Gpg4win (as User with Administration Rights)
  • Add another account with an Umlaut,e.g. "Maus Münster" or "Östern" (Short way on Windows 10: Settings/Einstellungen -> Kontos -> Family and other Accounts -> weiteren Nutzer. Kenne Ameldedaten nicht -> lokales Konto)
  • Login as other user, try e.g. gpg -v --quick-gen-key irgendwas after the acceptance of passphrase the error message is Schlüsselerzeugung fehlgeschlagen: No such such file or directory.

[Please note that although this is a regression in GnuPG 2.2.23 the actual problem existed for much longer and made it impossible to use Unicode account names or other file names under Windows unless the name could be represented by the current one-byte code page.]

bernhard created this task.Tue, Oct 6, 3:02 PM
bernhard added projects: Windows, gnupg.
bernhard changed External Link from to, Oct 6, 3:04 PM

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

aheinecke triaged this task as High priority.Tue, Oct 6, 3:11 PM
aheinecke added a subscriber: aheinecke.

I can reproduce this.

bernhard updated the task description. (Show Details)Tue, Oct 6, 3:13 PM
aheinecke assigned this task to werner.Tue, Oct 6, 4:09 PM

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.

Will be fixed for the next release.

werner edited projects, added gnupg (gpg22); removed gnupg.Tue, Oct 6, 9:30 PM

Thanks for the quick analysis.

Out of curiosity, if it is easy to answer:
Where would an automatically running test need to be added to find a regression like this?
(Just asking, because I've just thought about what it would take if I would add such a test and wondered if the infrastructure is already in place or if this is a kind of defect that is hard to test easily, because of the involvement of gpg-agent and possibly pinentry (at least in the test that reproduced it first)).

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.

werner updated the task description. (Show Details)Fri, Oct 23, 1:39 PM
werner removed a project: gpg4win.
werner changed Version from 3.1.13 to 2.2.23.
werner changed the task status from Open to Testing.Fri, Oct 23, 1:45 PM

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