The next version will fix the wrong warning and also allow for an empty value.

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.

Note: menu_backsign can be enhanced to detect such a case in the same way it detects missing backsigs.

We should find a way to figure out the OpenPGP S/N even if OpenPGP is disabled. I'll ask Yubico.

Indeed we need to fix/enhance this to make testing of --quick-revoke-sig easier. See over at T5093

I recall that I had the same bug during development. Must have slipped in again - Good catch.

I forgot that we have LOCK and UNLOCK commands in scdaemon. This was implemented around 2005 but there are no more users in gpg meanwhile.

On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.

In short eddsa secret keys generated with current 2.3 can't be imported with 2.2, right? That will lead to a compatibility problem, so we need to fix that in 2.2.

The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.

I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.

Thanks for the info and my apologies for the regression. Please see my comment on T5045.

Unfortunately this new release has a regression affecting users with non-ascii account names. See T5098.

I am already working on it. The gpg command will be

I missed this one because I only searched for "revoke" ;-)

What can be done is to use gpgconf --list-dirs bindir as a fallback for pinentry.

Sorry, hhis is a bug tracker and not a help line. Please ask on a mailing list - see gpg4win.org or gnupg.org

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

For the Debian problem it might be better to use "gpgconf --launch" and we add an option here to wait for the daemon to be started. That can be implemented in gpg-connect-agent which then should get the same option.

Frankly, I do not like this change - in particulalr not for the stable branch. Having a timeout on connections is actually a Good Thing and better than to wait indefinitely. There is a high risk on regressions and that is not acceptable for the stable branch. The branch already had a couple of regressions in 2.2.2x and we need to fix them and not introduce others.

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.

Are you on Windows or Linux? What version of Kleopatra or Gpg4win are you using?

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?

But changing just the displayed S/N should not disturb anything.

gcc also warns about missing arguments and hopefully also if the arg for %n is not an int*.
You may need to enable these warnings which we do at least in maintainer-mode. On Windows some of the warnings might be wrong because mingw assumes the MS implementation.

Nope %n works on all implementations I am aware of. It has to because it is part of even C90.

Sorry, it is entirely non-sense to ban useful printf features. Also note that we use our own printf implementation to avoid portability problems with for example "%zu". If you have a problem with any of the uses of "%n", please explain the problem.

Please understand that this is a bug tracker and not a support line.

The user is asked for a passphrase only if the key has a passphrase. I am still in favor of making a passphrase optional and then we need an extra dialog. Better safe than sorry. Those who have a workflow which includes the export of the secret key can still use the command line.

Caching issue. do_writecert in app-piv flushes the cache but may be the wrong DO. Can you try to