Okay, I have the same problem at my office and thus I should be able to figure out the reason. I have ignored the problem until now because the wokraround is easy enough and in most cases I authenticate with my token anyway. But yes, this needs to be fixed.

I assume this is the Windows version. gpg uses a locking mechanism to avoid creating several gpg-agent processes. In the worst case this may take quite some time until one of the processes can get the lock. There is an exponential backoff scheme in use and I have not yet found a way to replicate the full deadlock you describe. It would be helpful if you could describe in more detail how you run into this case.

Using a not yet existing directory is a security feature. The directory is created at a time the signature has not yet been verified and thus it would be too easy to trick a user into overwriting important data.

I think the code is using https://en.wikipedia.org/wiki/Estrin%27s_scheme but I have no scholarship applying this to AES-GCM. I will have to look closer.

Thanks for prompt answer!

Thanks for the detailed report. Does the green LED blink fast when it does not work?

Still reproducible with current master of everything.

I had a quite old master of libgcrypt (probably from August 2). I'll update everything to master an retest.

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.