It should be possible to apply the patch rG7de9ed521e516879a72ec6ff6400aed4bdce5920
for 2.2 also to older 2.1 or 2.2 versions,

That keeps the group permissions of an existing directory. Needs to be backported to 2.2

The fix we have there has the problem that it forcefully changes the permissions. Consider the case that for example that group access was provided which will currently be reset with each start of gpg-agent.

Checkout the taskbar. While creating the key you should get a (blinking) notification for pinentry - the tool to enter the passphrase. Under some circumstances Windows won't pop up that tool and you need to click on its icon in the taskbar.

@gniibe: Actually I implemented this recently. Support for this is in gpg-card

On an OpenPGP card the key no 1 (OPENPGP.1) is a sign-only key - you can't use it for decryption even if you somehow managed to encrypt to that key. That restriction is enforced by the card.

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.

I will consider a -p option for gpgtar.

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.

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

Unfortunately you can't pass extra arguments.

This has CVE-2020-25125

2.2.23 has been released and announced.

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

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.

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.

gpg-agent has only very limited support for ssh certificates which is the reason that your command fails.

I should add a test with Gnuk to my Windows quick test after a release.

There is not a lot of demand for this, thus we have not continued to think about it.

As a workaround please run

Let's continue discussion at T5040

There seems to be a problem with Gnuk and thus Nitrokey tokens with 2.2.22. We are investigating this. See T5039.

If we can use the code please first commit the original code to the repo and only then apply code style fixes.

We need to clarify two things:

FWIW, here an example of warnings we use. Yes it starts with -Wall but there are a couple of more specific warnings and at a few places we even use pragmas to disable warnings. And it depends on the compiler version used.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and warnings we ignore with gcc.

Fixed in gnupg and gpgme. it is not serious because that is just a failsafe check; libksba creates these strings and it does it correctly.

We have the same flaw in gnupg.

I think we should make zlib a mandatory dependency.