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

[Nathan Kidd]

On 2023-11-23 4:32 AM, Ludovic Rousseau wrote:
> Le jeu. 23 nov. 2023 à 00:05, Nathan Kidd <nathan-ml at spicycrypto.ca> a écrit :
>>
>> On 2023-11-22 5:15 PM, Ludovic Rousseau wrote:
> 
>>> 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.)
> 
> It will work if the client supports *more* readers than the server.
> The readers list will just be filled with empty readers with no (bad)
> side effects.
> But if the client supports *less* readers than the server the list
> will be truncated on the client side and some readers will not be
> usable by the client.

Yes, the server would necessarily truncate how many it sends.  From my
POV it seems a small and very improbable price to pay for making it
work, but perhaps you have more insight into the real world scenarios
where the user requires access to more than 16 readers. (Obviously Red
Hat thought they needed more, but PCSC's default seems to agree it is rare.)

> It will also work only if the server is newer than the client, not the
> other way.

To work the server and client would need to be new (server to send 4.5,
client to send CMD_SET_READER_COUNT).  If either side continued to be
4.4 they would function identically as before.  Fundamentally if people
want improvements they need to update their software. I don't see an
issue here, or any way to avoid that.

> I don't really care to be backward compatible with previous versions
> of pcsc-lite.

The fact that the version numbers have been bumped in the past means we
have incompatible versions in the wild and whether cross-host or in a
flatpack, we can't guarantee they are compatible.

Differing PCSCLITE_MAX_READERS_CONTEXTS values mean we're not even
guaranteed current-version compatibility between pcsc-lite and pcsd.

If your design decision is not to include compatibility for older
versions then perhaps I understand your POV a little better.

Would you prefer a solution that e.g. requires 4.5 versions on both
sides and then completely breaks compatibility but handles the number of
readers in a more elegant/dynamic way?

> I like Free Software because I can fix bugs and I don't have to adapt
> to bogus/limited code.

I have a lot of appreciation for the pain of maintaining backwards
compatibility, but when you can't control both sides the only
alternative is pain for users.  I think the X server did a decent job of
handling that scenario: query a version to know what requests are valid.
Requests never change, only new ones are added.

Appreciating your feedback and comments.

-Nathan