Your problem seems to be that you don't have a copy of your public key anymore. The uni-mainz keyserver might be configured not to return expired keys (if I read the output above correctly). I was able to to retrieve your key using the standard pool (in particular from the server sks.pod02.fleetstreetops.com). The key is expired but that does hinder you to decrypt. Run "gpg --card-status" once tomake sure a stub file is available.

Now I changed the gpg2 keyserver and can see my public keys on the public key server:

I will consider a -p option for gpgtar.

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.