[Pcsclite-muscle] Client code review request

[Ludovic Rousseau]

2014-11-13 18:21 GMT+01:00 David Woodhouse <dwmw2 at infradead.org>:
> On Wed, 2014-11-12 at 19:53 +0100, Ludovic Rousseau wrote:
>> 2014-11-12 18:55 GMT+01:00 David Woodhouse <dwmw2 at infradead.org>:
>> > On Wed, 2014-11-12 at 18:18 +0100, Ludovic Rousseau wrote:
>> >> 2014-11-12 17:39 GMT+01:00 David Woodhouse <dwmw2 at infradead.org>:
>> >> > Should I be worrying about SCardReconnect(), and doing something like
>> >> > the example in http://pcsclite.alioth.debian.org/pcsc-lite/node13.html?
>> >> > Or does the use of transactions save me from that concern?
>> >>
>> >> Why do you think you would need SCardReconnect()?
>> >
>> > Because I see warnings about having to do so if SCardTransmit() and
>> > other functions return SCARD_W_RESET_CARD... but I have no real clue
>> > when/if they might actually *do* that in practice.
>> >
>> >> It may be the case if another application has reset the card. But
>> >> maybe the use case would be to remove and insert the key again.
>> >
>> > OK, thanks.
>> >
>> > I have it building and running on Windows too now, but I always just get
>> > SCARD_W_CARD_REMOVED from the call to SCardConnect(). Is that my fault,
>> > or just Windows being its normal difficult self?
>>
>> Sorry. I can't really help on Windows.
>>
>> You may want to start with a very simple program [1] on Windows.
>
> This turned out to be a problem with the device. It has optional support
> for pressing the button to virtually 'eject' and 'reinsert' the card.
>
> I *enabled* this 'virtual eject' mode, and now I can press the button to
> make the card appear and disappear, and it works in Windows too.
>
> I disabled that mode again to check that I'm not going mad ? and it's
> really true that although the card is unconditionally present under
> Linux and OS X, it appears as unconditionally *removed* to the Windows
> VM.

I am not sure I follow you here.
Adding a VM in the equation is always adding complications.

But if it works for you then that is fine.

> My last question for now, I think: in what character set are the reader
> name strings returned from SCardListReaders() and given to
> SCardConnect()?
>
> Obviously in Windows we can use the UTF16 SCardListReadersW() and
> SCardConnectW() abominations, and modern systems using pcsclite *ought*
> to be UTF-8 everywhere. But are there any circumstances under which
> pcsclite will give me legacy 8-bit character sets?

Legacy 8-bit character set is something like ISO 8859-1 (also known as Latin-1)?

> For CCID it looks like the names currently all come from Info.plist, and
> never from USB descriptors? Is that right?

Exact.
So if your Info.plist contains "garbage" then will also do the PC/SC name.

> I thought there was a USB
> class so we didn't *need* a comprehensive list of vendor/device IDs?

Exact.
But pcsc-lite has no (yet) support for a class driver.

> Putting non-ASCII into Info.plist appears to make the file fail to parse
> ? although that file starts with <?xml version="1.0" encoding="UTF-8"?>
> it *isn't* actually parsed as XML.

On GNU/Linux it is parsed (by pcsc-lite and libccid) using a hand made
parser: tokenparser.l [1].
Valid characters are: ([A-Z]|[a-z]|[0-9]|[ \t]|[!@#$%^&*()\-+/_\:?.,=~'";\[\]])+

Do you need real UTF-8 reader names?

> But what about other IFD drivers ?

No idea.

Bye

[1] http://anonscm.debian.org/viewvc/pcsclite/trunk/PCSC/src/tokenparser.l?view=markup

-- 
 Dr. Ludovic Rousseau