The following patch make it work:

See
https://lists.wald.intevation.org/pipermail/gpg4win-announce/2020-September/000089.html
for the fixed Gpg4win 3.1.13

Gpg4win 3.113 has also been released. Thus closing this issue.

Winepath starts calls the full Wine engine just convert file names to DOS format. This is used by libtool but if winepath can't be executed, it doesn't care. So the given solution (using /etc/alternatives/winepath -> /bin/false) can be used.

So, if there's no support for native OpenSSH yet, I'll wait for it. After it's supported, I should be able to get the scenery I described working, right?

Small correction: The fixed byte I talked about may have the values 1, 2, 3, or 4.

Unfortunately you can't pass extra arguments.

Thanks for your information. No debug output any more, as I already figured out things.

This has CVE-2020-25125

2.2.23 has been released and announced.

The fix will be in the 2.2.23 release (T5045).

In case of Ed25519 certificate signed by Ed25519 key with only few names and flags it seems to be just below 500 bytes. This could of course grow if names are added or larger public key is being signed.

@bvieira You need to set pinentry-mode=loopback for gpg program used in git.

To implement this it would be best to have an gpg_strerror variant which does not call dgettext.

re 1: Correct utf-8 truncation would be quite some work. In this case the message is in the Assuan interface is a debugging aid. Translation is not necessary so we can try to disable it.

You need to get you toolchain correctly installed.

After randomly finding this issue I wonder: Is it possible (and does it make sense) to change the title of this bus to something like "big key causes massive CPU usage" (if I understood it all correctly)?

Well, from the viewpoint of card specification, "a message M of arbitrary size" for Ed25519/Ed448 in RFC8032 is not good, because card has a limit for buffer size and the protocol in the OpenPGP card specification requires the steps of (1) the message M is buffered and then (2) the compute the signature.

It's a different issue: Gnuk doesn't support length of 3072, only 2048 and 4096.

Thanks for your reply, but it is an OPTIONAL feature. The annoying part is not deleting the files. Comparing hundreds of time stamps to ensure you are current on what you want encrypted vs. unencrypted files that are either under development and/or complete, and therefore ready for encryption. This frequently needed comparison takes a significant amount of time, and is prone to error. Any responsible user will ensure there are tested file backups to prevent catastrophic losses, or they can simply NOT use the option.

A bug was reported against this version which could happen also to older versions of GnuPG 2.2. In case of a crash please apply the patch over at rG8ec9573e57866dda5efb4677d4454161517484bc or wait for 2.2.23

See https://bugzilla.opensuse.org/show_bug.cgi?id=1176034 for the original bug report. I was not able to replicate the crash but the bad reads. The error is pretty obvious: The code expects that all fields are zeroed out.

I'm actually trying to do the following:

In the meantime you can use [0]. I have tested with ssh key on yubikey and AuthenticationMethods publickey, win32-ssh (or ssh-portable, which is the new repository name) correctly works with gpg and pinentry is called. Despite it being called wsl, wsl environment is not required.

Hi,
I have tested a GnuPG Token with Gpg4win-3.1.12 and generating a key with Kleopatra did not work
With 2.2.23-beta4 that contains: 0a9665187a7cbf68933b7162fb5f974177684a50 I have repeated the test on Linux and first the key-attr change that Kleopatra sends fails:

See also: T3506

I have removed that feature intentionally. There were some issues where encryption errors were not properly reported to Kleopatra and handled by Kleopatra. This could result in catastrophic data loss. I have fixed ~3 issues regarding to that and then decided that in our architecture we cannot absolutely guarantee that this never can happen and cannot happen in the future. We have resolved all the issues, but they could occur again.

I just confirmed that Gnuk has a limitation for the input length is less than or equals to 256.
So, this is the issue of Gnuk, not GnuPG (or at least, Gnuk has the problem).