I cannot reproduce this problem anymore. Neither with the test case
script, nor during ssh authentication with several card-reinsertions.

Is this still an an issue (2.0.4 is pretty old)?

Moritz, this should be fixed in the current SVN of 2.0.10. Would you mind to
test it?

Just as a quick follow-up to this script I wrote:

Moritz Schulte created a test case for this or a similar problem:

(Assigning to Werner, because the Problem is still there.)

The problem is still there with
Kontact proko2 2.1.12 and gnupg-agent 2.0.9-0kk2 on Debian Sarge.
And Kontact enterprise35 20080826.852422 Etch.

the username/philkime thing was just a typo, should both be "username". I can't
remember what the problem was any more, just that using "eval gpg-agent ...
didn't work properly and the agent couldn't be contacted when using
--use-standard-socket. I worked round it by just ignoring the STDOUT output of
gpg-agent when started and assuming that the socket is at ~/.gnupg/S.gpg-agent.
I think this issue can be closed.

Did you su to root and thus kept $HOMe at the old value? I do not understand
why you have "username" in the ls but "philkime" in the $HOME (which gpg-agent
uses to construct the name of the socket).

Upgrading from 2.0.7.svn4643-0kk1 and from 2.0.7-1kk2 to 2.0.8-0kk1 worked fine.
(tested on two machines, both having a running gpg-agent and then decrypting
OpenPGP and S/MIME messages)

You are using an old gpg-agent which does not support this option.
Below is the patch to allow using an old gpg-agent (I will commit it later).

Hmm - which part couldn't you replicate? I think you're right about the ssh
functionality - I think that's perhaps what I hit. But isn't it confusing to
have gpg-agent report a socket number it doesn't use when started with
--use-standard-socket? Or maybe that's what you couldn't replicate? Here is a
typescript of what I see:

I fixed it in agent/* and common/*. However, I don't think that this fix is
needed. It later turned out that we are already running gpg-agent with gettext
clamped to utf-8 to that the fix does nothing.

Werner,
thanks for the fix.
Just quickly?
In which component did you fix it? Is there an easy way to get a patch?

Works for me. However I was not able to replicate the original case because I
have no 2.0.5 available.

I found and fixed the problem. Now testing...

$ locale
LANG=de_DE@euro
LANGUAGE=de_DE:de:en_GB:en
LC_CTYPE="de_DE@euro"
LC_NUMERIC="de_DE@euro"
LC_TIME="de_DE@euro"
LC_COLLATE="de_DE@euro"
LC_MONETARY="de_DE@euro"
LC_MESSAGES="de_DE@euro"
LC_PAPER="de_DE@euro"
LC_NAME="de_DE@euro"
LC_ADDRESS="de_DE@euro"
LC_TELEPHONE="de_DE@euro"
LC_MEASUREMENT="de_DE@euro"
LC_IDENTIFICATION="de_DE@euro"
LC_ALL=

$ gpg-agent --version
gpg-agent (GnuPG) 2.0.0
...
$ scdaemon --version
scdaemon (GnuPG) 2.0.0
...

What version of gpg-agent and scdaemon are you running?

Can't duplicate this problem.

Sorry, I can't replicate this using gnupg 1.9.92.
If you are still able to replicate it please create a test key and decribe
exacly what I have to do.