[Pcsclite-muscle] Fixing PCSCLITE_MAX_READERS_CONTEXTS assumption / incompatibility in PCSC protocol

[Nathan Kidd]

Hi,

The idea behind PCSCLITE_CSOCK_NMAME is great, allowing to forward the
socket wherever you want. Unfortunately you currently can't use
PCSCLITE_CSOCK_NMAME socket forwarding between Red Hat-based and
Debian-based distros because they use a different
PCSCLITE_MAX_READERS_CONTEXTS  value.  I'd like to solve the problem.


Background
==========

PCSCLITE_MAX_READERS_CONTEXTS is defined[1] as 16 in the main repo and
Debian-based distros but is tweaked to 48 in Red Hat and related
distros.  This value controls the state struct size which ends up as a
hard message size requirement in the PCSC socket protocol.

The result is if you set PCSCLITE_CSOCK_NAME to point to a socket on
another Linux box which has a different PCSCLITE_MAX_READERS_CONTEXTS
value then you'll either:
 - Hang the app immediately (because it wanted 48 structs worth but only
got 16 in the socket), or
 - Error (at best) in the app (because it read 16 structs worth but had
48 in the socket, so when it was time to read the next request reply it
read the 17th entry instead of the reply it expected).

You can also see this problem being hit here
https://github.com/neutrinolabs/xrdp/pull/1825

The solution to this problem would help solve
https://github.com/LudovicRousseau/PCSC/issues/8 but it isn't the same
problem exactly.


Proposed Solution
=================

 1. Bump PROTOCOL_VERSION_MINOR to 5

 2. If libpcsclite gets a CMD_VERSION reply from pcscd of >= 4.5 then it
will immediately send a new CMD_SET_READER_COUNT request that looks like:

typedef struct reader_count_struct {
    uint32_t count;
    uint32_t rv;
};

 3. If pcscd receives a CMD_SET_READER_COUNT it will then use that
dynamic value for future CMD_GET_READERS_STATE and
CMD_WAIT_READER_STATE_CHANGE replies, writing that many struct payloads.
If given an insane count value the server can reply with an error.

I don't have time to produce this patch immediately but I wanted to get
the ball rolling to see if there is an agreed technical approach.
I have been using this solution with success in a custom product[2] but
it is better for the industry if we have an agreed common solution.


Thanks for your feedback.

-Nathan


[1]
https://github.com/LudovicRousseau/PCSC/blob/a0033653b2ac62abb04165a36a4dbd56c68a1a80/src/PCSC/pcsclite.h.in#L284