Additionally, does your answer imply that when I ssh into remote, no gpg logs on remote should be produced if everything is executed correctly?

I see. How should I prepare environment instead? With local it is clear, but with remote it isn't. I also use remote as a normal machine with yubikey plugged directly into it most of the time, as it is a desktop at home. Local is a laptop that I use when I'm not at home. So, let's say I have a fresh reboot of remote and use it a bit with yubikey. So, it has gpg-agent started with its own socket there. Now I want to ssh into remote. If I understand correctly, for correct functionality I need to kill gpg-agent on remote first, otherwise agent forwarding will misbehave? Then, after I'm done with ssh and get back to remote (physically), how do I "recover" from ssh and re-launch gpg agent normally again? Since you say that killing it will send instruction to kill it on local machine, what should be done instead?

You should not do gpgconf --kill all on your remote machine; It kills gpg-agent on your local machine, through forwarded socket. And next invocation of gpg will invoke gpg-agent on your remote machine, which makes things confusing.

I didn't run gpg-agent or scdaemon on remote manually. If that happened -- it probably happened as a result of ssh'ing into it and spawning a zsh shell, which executed the section that I mark as "Environment (per shell)" above. I do this kind of "preparation" (stop gpg, clean up logs to collect only relevant logs on problem demonstration) to make the problem description as minimal as possible. And I post all relevant produced logs to make the problem description as complete as possible. Sorry if this is confusing, I don't really know what I'm doing but I want to make a bug report that can be acted upon.

Sorry, my editing error. I wanted to write:

Thank you for the response.

Perhaps, for the usability, it would be good for gpg-agent's "extra" access to allow some of SCD commands.
This can align the current limitation, I suppose.

The data object 0x00FA is now supported. And other changes are not needed.

I think that your configuration does not work well for gpg --card-status when you want to use local scdaemon service from remote machine.
By using "extra" socket, only a few commands are allowed to execute.

Fixed in Gnuk 1.2.16, although it still has a limitation by the I/O buffer size.

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.