I can't replicate it with a card initialized the standard way and revoking the
encryption key. Will test later with only the subkey on the card. This is
using gpg2 or gpg-1.4.9 along with scdaemon.

Duh, this is already implemented:

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

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:

Meanwhile we have greatly improved gnupg on w32. See www.gpg4win.org. Thus it
makes no sense to care about this old bug anymore. If the problem still
persists with Gpg4win 1.9.9, please re-open this bug.

$ 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?

I did again some tests using a fresh card and clean build of all modules. Still
no problems except for the led keeping lit after a verification. However I am
not sure whether this is an error or expected behaviour.

2.0.1 has been releaaee some time ago and we received no complaints.

2.0.0 has been released.

Thank you, I will look forward to it.

However, I will risk it and release 2.0.1 with RESULTLEN increased to 258.

are you means there some old pcsc driver will eject a out buffer with 258
bytes? as my experience, many pcsc driver will handle this correctly.

Well, it would harm. It passes 258 to the PC/SC layer and that may choke on it.
I hesitate to change this given all the faulty cards out there. It would cost
me a serious amount of time to run regression tests on all the cards.

You are right. I recall that I had problems with some cards with Le=0 in the
GET RESPONSE but there is no actual check for it and thus the suggested change
can't harm.

the card is developed by me, i'm not sure whether i can send it to you. the
fault was caused by the out buffer is too samll for store the response data
and the status word, in my case the apdu send to card is: 00 C0 00 00 00,it
requires 258 (256+2) bytes to store the outter data, however the buffer
provided by the program is 256 byte, the pcsc back end will failed to handle
this apdu.

It depends on the card. I don't have any card with 2k RSA keys here. The
change you suggested is likely to break other stuff. The correct way to return
longer results is by using GET RESPONSE. scdaemon will handle this
automatically but some cards may not allow for it. What card is that, can you
send me a sample?

my card reader is Gemplus USB: Gempc-usb-sw, the reader backend is pcsc, i
using other pcsc software with this reader, it can support the function
correct, this feature is very important to me, because my card can support
long RSA key, such as 2048 bits, and GunGP cann't work with suck card.

What card reader and what reader backend are you using (pcsc or ccid)?
Do you need this for supporting extended APDUs?

sorry, it was in the line 2710

I don't have an immediate answer to this. Need to fire up the debugger.