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

Please ask your distribution . What I see here is a problem with the packaging of a dedicated build system. This is not the build system which comes with GnuPG. Feel free to reopen if you can show that this is a native gnupg build problem.

Should not be too complicated.

That is a version of gpg4win which we don't support or even know about. Please ask at their support site. Sorry.

We do have an Italian translation but it is quite outdated:

Thanks for the report. Indeed, the convenient C99 feature of variable definition in a for statement does only work in recent gcc versions and thus it should not be used in GnuPG related code. (https://gnupg.org/faq/HACKING.html was out of sync with the version in gnupg's master repo which falsely stated that it is an allowed features.)

The name field is marked as optional but it is mandatory. This should be fixed.

You used custom options which did not pick up the proper libksba. Install libksba correctly then try again. Please direct further questions to the mailing list and please build the latest version 2.2.23 and not an arbitrary old version.

Version 2 is a bit too unspecific. Which version of what software are you using. Which OS?

There is a conflict between the systemd based launching of gpg-agent and gpg's own launching of the agent. Further systemd seems to remove the /run/user/UID directory which unlinks gpg-agent's socket. gpg-agent's self-check notices this after a minute and termintates itself.

With 2.3 we add the keyboxd which uses sqlite (and thus indices) as database. This makes lookups much much faster and avoids problems with several processes accessing the pubring.kbx. If you want to try this you can do so with 2.3:

That code in gnupg has not been touched in a very long time so this may be caused by some side effect.

I am sorry, but I do not understand your request. Please give real commands as examples.
You known that you can always use --output FILENAME to force a certain file name?

I am sorry, but this is a bug tracker and not a help list. I don't even known what Electrum is. Please ask at their support site or if you are looking for general help with GnuPG post to the gnupg-users mailing list (see https://gnupg.org/documentation/mailing-lists.html)

Please do not use addkey with in such a way. The use of "canned"commands way work now for you but can lead to unexpected results if anything changes, either due to changes in another gpg version or due to changes in your key etc.. The correct use requires a state machines along with --stattus-fd and command-fd. Because that is quite hairy to get right we have added a set of quick commands. In your case your should use

FWIW: You may get a faster answer if you post to gnupg-users mailing lists. Bug reports are a tool to fix bugs and usually are only seen by a few developers.

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.

Here is the output for an SCM SPR532

Bus 001 Device 123: ID 04e6:e003 SCM Microsystems, Inc. SPR532 PinPad SmartCard Reader

Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

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.

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

Thanks for the detailed report. Does the green LED blink fast when it does not work?

Are you using libgcrypt 1.8 or master (to be 1.9)?