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

[Nathan Kidd]

On 2023-11-22 5:15 PM, Ludovic Rousseau wrote:
> Le mer. 22 nov. 2023 à 22:18, Nathan Kidd <nathan-ml at spicycrypto.ca> a écrit :
>> 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 like your solution because it does not really fix the problem.

If we define the problem as "make cross-linux communication work", can
you describe why you don't see it fixing the issue? (Modulo the version
issue addressed below.)

> See also:
> - use a list instead of a fixed size array for 16 reader states
>   https://salsa.debian.org/rousseau/PCSC/-/issues/4

(On the server side we'd need some form of dynamic storage, yes.  The
minimal fix could still use static storage with a global that defaults
to PCSCLITE_MAX_READERS_CONTEXTS to maintain backward compatibility.)

> - Support multiple versions of the internal protocol: fix Flatpak issues
>   https://salsa.debian.org/rousseau/PCSC/-/issues/22

Ugh, I checked the client-side was ok with version mis-match but forgot
the server-side. That's a bit painful.  (In my testing I'm using a
custom server where I don't reject version mismatch.)

Proposed Solution 2
===================

1. Introduce separate major and minor version defines for client and server

2. Bump only the server minor version

3. If client sees server >= 4.5 send CMD_SET_READER_COUNT

(Getting out of the "it isn't possible to change the client version"
hole is a separate issue.)

This solution seems the minimal fix to me, but I'm not trying to push
this.  If you have some alternate plan or architecture in mind I'd be
glad to hear it.

>> 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.
> 
> Your link for [2] was missing.

(It was. It is a custom PCSC proxy that runs on Linux and injects
CMD_SET_READER_COUNT after querying what the native libpcsclite was
compiled with, then forward's to our Exceed TurboX client on Windows
that runs a custom PCSC-compatible server.)

-Nathan