Bug 2054826 - Support of more than 16 smartcard readers breaks flatpak interoperability
Summary: Support of more than 16 smartcard readers breaks flatpak interoperability
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: pcsc-lite
Version: 35
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-02-15 19:06 UTC by Bryce Nordgren
Modified: 2022-11-02 16:47 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2022-11-01 15:30:54 UTC
Type: Bug
Embargoed:
fedora-admin-xmlrpc: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker FC-391 0 None None None 2022-02-15 19:19:55 UTC

Description Bryce Nordgren 2022-02-15 19:06:20 UTC
Description of problem: Patch to the pcsc-lite and pcsc-lite-ccid packages breaks client/server compatibility with other platforms, like flatpak. pcsc flushes a fixed sized buffer to the socket and client and server must agree on that size.


Version-Release number of selected component (if applicable):
pcsc-lite: 1.9.5
pcsc-lite-ccid: 1.4.36

How reproducible:
Always. 


Additional info:
Read the following for upstream's identification of this problem:
https://github.com/LudovicRousseau/PCSC/issues/118
https://ludovicrousseau.blogspot.com/2022/02/fedora-flatpak-and-pcsc-lite.html

The choice here is: retain the patch to support more than 16 smart card readers, knowing it breaks flatpak (and other container) usage; or package an unmodified version of pcsc-lite and pcsc-lite-ccid in order to support flatpak users at the expense of those who need more than 16 smart card readers.

Comment 1 Jakub Jelen 2022-02-15 21:53:14 UTC
Thank you for the report.

We are using the "more than 16 readers" in RHEL for quite some time, indeed, with the assumption that these two (pcsc-lite and pcsc-lite-ccid) will only talk to each other. We dropped the patch to Fedora just recently to gather exactly this feedback.

The git archeology brought me to a bug (private bug #1112846) from 2014, where a customer used more than 16 readers and used a variation of this patch. Unfortunately, this was never brought up to upstream.

Unfortunately, there is no other way to bump the number of the readers than bumping the constant, hoping this will not be considered as a public API by some application (or container). In any case, protocol with fixed size list sounds a pretty fragile (especially if the internal sockets are passed around between containers).

Ideal solution would be to implement support for dynamic reader lists as mentioned by Ludovic, but that sounds like a long run.

We might temporarily revert the change before we would find a better solution. In any case, I will keep you updated.

Comment 2 Bryce Nordgren 2022-02-15 22:31:02 UTC
My guess is that redhat has better staffing than Ludovic does...and probably makes more money off of enterprise linux users. Any chance y'all can put together a pull request for him that: 

* Modifies the protocol to transfer a list instead of a fixed buffer
* Falls back to the current protocol should the peer be incapable of using the new version

Just asking. :)

Comment 3 Jakub Jelen 2022-02-17 16:20:07 UTC
Red Hat is not only smart card support. Indeed we have hundreds or thousands of engineers with different focus areas. There are also hundreds of packages of different complexity and bug/rfe traffic. There are packages that are getting much more focus and development than pcsc-lite so I would love to say that I can do it, but its not just about putting together a PR, but more about getting better understanding of the code, drafting some protocol, agreeing with Ludovic that it might work for upstream, implementing the changes (ideally testing it too) and only after that the PR can land. But I have also other packages to work on so this is not getting super-high priority, but I would personally be interested in having this resolved in some acceptable way for all involved parties (pcsc-lite upstream, rhel, flatpack), but I can not promise when it will be.

Comment 4 Ludovic Rousseau 2022-02-20 21:59:48 UTC
Hello Jakub,
I can't access the bug #1112846 you mentioned: "You are not authorized to access bug #1112846.". I guess that is expected.

I would love to work on solving this problem for RedHat. I propose to continue the discussion in private. I think you already have my email.

Comment 5 Trevor Clark 2022-02-26 15:44:32 UTC
This bug I opened with remmina is probably related. I can share smart card with remote with the rpm remmina, but not he flatpak.

https://github.com/flathub/org.remmina.Remmina/issues/97

Comment 6 Pierre Ossman 2022-04-05 05:46:04 UTC
This is preventing our flatpak from using smart cards on Fedora as well:

https://github.com/flathub/flathub/pull/2931

Comment 7 Jakub Jelen 2022-11-01 15:30:54 UTC
I just removed the offending patches in rawhide as we were not able to come up with any better solution. Closing.

https://koji.fedoraproject.org/koji/taskinfo?taskID=93668863
https://koji.fedoraproject.org/koji/taskinfo?taskID=93669203

Comment 8 Debarshi Ray 2022-11-02 09:50:48 UTC
Thanks, Jakub.

Just to be clear.  I do want to help you with supporting more than 16 smartcards by making the necessary changes in Flatpak and elsewhere.  It's just that I have too much to do.  For example, right now I need to fully focus on Toolbx at least until the end of 2022.  Then when I am able to get back to Flatpak, I have to keep shuffling my to-do list as per the priorities at that moment.  There's always so much to do.  :/

Comment 9 Ludovic Rousseau 2022-11-02 16:47:10 UTC
Debarshi, I don't think you can do anything in Flatpak to fix the issue.

pcsc-lite should be updated to use a more flexible protocol and also support more than 16 readers natively.
I made that proposition to Jakub/RedHat but without a positive answer for now.


Note You need to log in before you can comment on or make changes to this bug.