That might depend on your pinentry version. With a pre-1.1.1 pinentry and 2.2.28 I get this:

The show error is due a missing translation. What happened was that the translation was marked fuzzy and this marker was removed not realizing that the string really changed. The change was "...in the GnuPG system" -> "...in the %s system" which had been done to allow for different gpg names.

Start from scratch on a german system, even when you do a gpg --version it shows it is in german. Then import a PKCS#12 container and the dialog is in english.

A wild guess is that the different envvar systems we have in use are the culprit. It is anyway time to get this straight.

As suggested in the linked question on stackexchange, I think that even if the error comes from the pinentry program, GnuPG could echo a more informative error than gpg: decryption failed: No secret key, such as terminal to little to show the pinetnry program, or something similar.

Thanks for the report. Frankly the curses pinentries are not that widely tested.

The now used /var/run thingy solves all these problems nicely. In fact we may eventually remove the use fallback of using sockets in the GNUPGHOMEDIR.

See T5267: Ed25519 backward compatible private key support for preceding ZERO(s) for the fix.

rG47c1c329ed82: agent,ecc: Use of opaque MPI for ECC, fixup 'd'. does the fixup when reading keys.

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.

If your problem is the incompatibility between standard OpenSSH (server) and PKIXSSH (client) for use of ssh-agent emulation of gpg-agent with ECDSA key, I'd suggest to apply following patch to your PKIXSSH:

diff --git a/compat.c b/compat.c
index fe71951..0c9b1ef 100644
--- a/compat.c
+++ b/compat.c
@@ -245,7 +245,6 @@ xkey_compatibility(const char *remote_version) {
 {	static sshx_compatibility info[] = {
 		{ 0, "OpenSSH*PKIX[??.*" /* 10.+ first correct */ },
 		{ 0, "OpenSSH*PKIX[X.*" /* developlement */ },
-		{ 1, "OpenSSH*" /* PKIX pre 10.0 */ },
 		{ 1, "SecureNetTerm-3.1" /* same as PKIX pre 10.0 */},
 		{ 0, NULL } };
 	p = xkey_compatibility_find(remote_version, info);

Unfortunately and confusingly, PKISSH returns "OpenSSH" when asked by "ssh -V".
Please install real OpenSSH, if this is the case for you.

Quote from IRC:
hey, i've some problems with my smartcard since quite some time. i'm not sure whether it's openssh related or gnupg. it's a openpgpcard v2.0 and i have to workaround ssh logins by using "SSH_AUTH_SOCK=0 ssh ...". .gnupg/gpg-agent.conf -

Yeah but it seems to be the same issue / reason. I wasn't aware that PKISSH is something else. I thought it was an extension/protocol or something

I added "Feature Request", because this is a request to support:

• A feature of bug compatibility, which is implemented wrongly in PKISSH
• for a specific algo of key, which is not considered so useful (== ECDSA)
• PKISSH, which is variant of OpenSSH

In T4563#140184, @idl0r wrote:

I was and I am using OpenSSH on both sides, client and server.

I was and I am using OpenSSH on both sides, client and server.

I do not think that we should support a fork of openssh right now. If we would support it we are bound to maintain that for years - this is not a good idea.

Well, I have no idea about the technical background to be honest but without this patch it doesn't work at all for me, unless I stop using the agent or workaround it by using SSH_AUTH_SOCK=0. With this patch, I can use the agent again. I don't know how many others are affected by this but it made it usable again, which wasn't the case for months already.

In theory, I don't think the patch gnupg.patch works. It just ignore the flag.

I am affected by the same bug and the patch seems to work for me. Login via gpg-agent with ssh support is possible again, which wasn't before, since some openssh and/or gnupg update. Not sure.

No more problems reported, so I assume like @aheinecke that it has been resolved in Windows.

Its done for 2.2 thus changing the tag.

I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).

{F1982353}

Thanks. I understand the situation. Basically, gpg-agent's computation is done by a single thread (in current implementation), although it accepts many requests simultaneously.

In T5137#139066, @werner wrote:

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

In T5137#139064, @gniibe wrote:

I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

If possible, please try adding arguments for gpg invocation: --pinentry-mode loopback --passphrase-file YOUR_FILE_FOR_PASSPHRASE
This can avoid the invocation of pinentry entirely.

I change this to a feature request: Allow several processes to run public key decryption using the same set of private keys.