D134: 305_used-scdaemon-doc.patch

We can't do anything about it.
Cards with manufacturer id 5 and serial numbers up to 346 (0x15a) are affected.
Newer cards work fine.

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?

This looks pretty much like a pc/sc problem. Please shutdown pcscd and use the
internal CCID driver. With PC/SC we don't have any control over the USB - we
don't even know what this is.

I checked this again and can't replicate this. The file is only written if the
status of the slot changed - independent of any client connection or the use of
SCD SERIALNO. If you lo updating slot 0 status: 0x0000->0x0007 (0->1)ok a the
logs (no options needed) you can clearly see that:

More info:

• scd killscd works when in the replug-without-hibernate case, for hibernate, a restart of pcscd is needed (probably not a scd problem).
• when I don't issue any commands to scd while the reader is unplugged, I can re-plug it anywhere (same or different usb port) and scd recognises this as a USABLE->ACTIVE->NOCARD->USABLE transition chain
• when I issue a SERIALNO command while the reader is unplugged, I get "Card Error" back (sitenote: shouldn't that be a ERR_NO_CARD_READER?) and that one sticks until a KILLSCD.
• this is not the case for other commands (tested: GETINFO version).

GPA works fine since it's full of sentinels blocking reentrance into the
reloading code, which I assume is triggered by the scdaemon behaviour
described. In addition, GPA causes the whole stack to wake up periodically to
reload data that didn't change. That's not nice for laptop users and
contributes to Global Warming :)

I see that this is a bit annoying. However I don't see the real problem. GPA
works just fine.

We should eventually do something about it. The problem is that you remove the
device and after plugging it in it is considered by the OS as a new device.
This also depends on the Os used and whether PC/SC, ctAPI or the internalCCID
driver is used.

The parser from libassun accepts lowercase variants. That is convenience
feature when working on the commandline with the assuan protocol. It should
never be used in any code. Attribute names are case-sensitive.

scd getinfo version

D 2.0.13-svn5059
$ ./src/gpa --version
gpa 0.9.0-svn996

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.