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.