PCSC
PCSC copied to clipboard
LudovicRousseau
Backward protocol compatibility
Recently in 2.3.0 pcsc release there was minor protocol version bump. This was first protocol bump in 6 years.
This creates problem for using pcsc in containers (i.e. flatpak) where there's one client version but multiple server versions. Not updating client means all new servers are broken - updating means all old servers are. How to prevent such hopeless situation? Is it possible to introduce protocol negotiation instead of mismatch failure?
Alternatively is it possible to revert above commit until solution for protocol compat is found?
Yes, it is a known issue. See https://salsa.debian.org/rousseau/PCSC/-/issues/22
I do not use flatpack myself. So I have no motivation to implement something.
I would love to work on a solution.
You can contact by by email. See https://blog.apdu.fr/articles/about_me/
Hi, was SCardGetStatusChange() added at someone's request? Do you know of any applications making use of this command yet? I am trying to figure out whether it's safe to hold on 2.2.3.
@minosimo SCardGetStatusChange() is part of the API since the beginning.
You can have a look at https://codesearch.debian.net/search?q=SCardGetStatusChange for some of its usage (626 results).
Oh sorry, I copied the wrong string! It should have been GetReaderEvents().
There is no GetReaderEvents in the source code. Maybe you mean CMD_GET_READER_EVENTS as listed in 53f57ed700bcd0bc47d970dc674ba3fd5ee5b387.
It has been added to solve the problem described in https://blog.apdu.fr/posts/2024/08/improved-scardgetstatuschange-for-pnpnotification-special-reader/
Hi Ludovic, I've run into this too, I have new-servers and a slightly older client. I appreciate this is a once-in-six-years thing.
Is it right to say that a newer client can talk to an older server, but an old client cannot talk to a new server?
Is it right to say that a newer client can talk to an older server, but an old client cannot talk to a new server?
No. You need to have the sever and the client using the exact same protocol version.
Minor version was updated from 4 to 5 to add a new command to the server. https://github.com/LudovicRousseau/PCSC/commit/53f57ed700bcd0bc47d970dc674ba3fd5ee5b387
If the client is at version 4 and the server is at version 5 then it should work since the client should not use this new command. Maybe I could integrate this commit from org.keepassxc.KeePassXC
One good idea would be for @droidmonkey to submit a PR. I think that is how Free Software development should work.
To be clear, @minosimo is original author of that patch that was borrowed by some flatpak apps. I didn't know it was acceptable solution for upstream. If it is then great.
The patch is a quick dirty solution to allow a flatpak application that bundles the latest client with protocol 4.5 to work with older servers with protocol 4.4.
My intuition says it is only safe to use if the application does not account for the possibility of multiple readers being connected as described in the blog post.
Past this point I am out of my depth. If the protocol bump added a new command for clients, it could return an error in the case of a protocol mismatch, but it looks like it expands SCardGetStatusChange() making it return additional information. I have no idea how to account for that, open to suggestions.
You are right perfectly @minosimo.
I may implement something like the patch https://github.com/flathub/org.keepassxc.KeePassXC/blob/23dacfd4af4fc11ad2e5751bf9db6ba0d43e2760/pcsc-lite-protocol.patch