This is a different thing. 644 is about serialization of pinentry pop ups.

What happens here is that your IM software uses several connections to the
gpg-agent and gpg-agent tries to answer them concurrently. This is in general a
Good Thing.

I can see that this is a bit annoying but it is a prety uncommon use case. In
general you use different keys for different purposes. Or in your case better
use OTR instad of OpenPGP. I can see how we can fix this but it will likely
require a changed flow of control in gpg-agent which is an error prone change.

Your IM software should use one connection for this task; running it in parallel
has no advantage at all. Anyway, if it wants to optimize things it could watch
out for the pinentry_launched inquiry and use this to detect whether it is
likely that more pinentries will come up. But again, a lot of code for a
questionable improvement. There is also a resource issue if it runs one
conenction per avtive IM account.

Thank you for your reply, werner, but I disagree with you on this.

I cannot see why a subsequent request for the same key gets handled differently
just if it occures before the passphrase has been entered completely.

Also, I think it must not matter if the same key is used multiple times from the
same app or from different apps. Imagine a few apps that are run by my desktop's
autostart feature using the GPG key from the beginning. As they are started in
parallel, they will propably all connect to gpg-agent before I entered the
passphrase for the first request. They cannot use the same connection for all
requests.

When gpg-agent (or pinentry) get a passphrase from the user (first pinentry
popup), no further asking of this key's passphrase should be done before timeout
is over. The pinentry popup windows themselves are serialized, they only appear
one at a time.

In this special case, maybe my IM app could do better. But the goal of gpg-agent
should be that several uses of the same gpg-key can share one
passpharase-input-dialog that appears only ONCE (before timeout period is over).

You may disagree but it is a matter of fact that changing this is quite troublesome.

From the user's view, I would say this is still a bug, no matter how complicated
it is to be fixed. :)

I can not (and don't want to) force you to fix this here and now but I think in
the long term, this is not a desired behaviour and should be fixed.

I changed the subject line to be more specific, so this one can sleep in the bug
tracker and won't be forgotten. :)

Thanks.

See also T1109 which describes the problem in a few words.

Duplicate of T1109