This is now a known problem. The likely reason is bug in the card's code. The
workaround is to forget about card based 3072 bit encryption keys.

Does the fact that I can encrypt, sign, and authenticate correctly with 3072 bit
keys affect your hypothesis?

According to http://pcsclite.alioth.debian.org/shouldwork.html#0x0B970x7762
this reader should work but it has not been tested.

Is there any more information I can provide? Can you reproduce it?

This is the built-in reader in my Dell Latitude D430, by the way.

This is the relevant lsusb output:

What card reader are you using?

Okay, fixed in SVN 4958.

Tested with gpgsm 2.0.10-svn4835 and pinentry-curses 0.7.4. Works fine now. I
did have to explicitly set GPG_TTY, though, to make pinentry-curses work, but
that's unrelated to this issue.

No response, assuming it has been fixed.

Done in 4888. For scdaemon this is a half second and for gpg-agent every third
second.

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.