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

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.

This is fixed now, but of course it will only affect the next release :-/

--locate-external-keys exists since 2.2.17 and ignores the local keys.

There are two problems that might be mixed in here:
What I noticed sometimes is that pinentry-qt properly becomes the ForegroundWindow but the input focus is not set on the line, even though an active cursor is shown in the line.
This might be a pinentry-qt specific issue and I look into that.

@gniibe I wonder, if file --export with following --import would do the trick!?

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

@leder I agree that it is useful if OpenPGP public key can be (directly or indirectly) retrieved from a card.

One more idea: It is a riddle to me why I can configure keyserver http://pool.sks-keyservers.net/ and then do a --search-keys, but it is impossible to do --receive-keys with the following error:

Thank you, gniibe!

I have run the DbgView test twice, I don't know if there is the data you need.

Please note that your private keys are on your card, together with finger print information. But there is no place to have OpenPGP public keys on the card. I guess that this is a possible cause of confusion.

Now I am even more confused! This is key No. 1 - the number on the keyserver w/ --search-keys:

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.

thanks for the report. Between Gpg4win-3.1.12 and Gpg4win-3.1.11 KF5ConfigWidgets was indeed updated so your report might point to a regression in that library.

Hello Werner,

Argh, that will also be shown when Kleopatra first starts and no keys are visible. This is caused by a change in Gpg4win to check the integrity of the Version by verifying that the VERSION file is signed.

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?