Repository navigation
ccid does not list RS-Key 0x1209:0x0001, so pcscd skips CCID iface and applets. #67
Description
Activity
Thanks for the careful write-up — you're right, and you're the third person to hit this. @ncmro7 ran into the same thing in #58 (
pcsc_scanshowing nothing), and @Curious-r named the cause there. It deserved to be in the docs long before now.Root cause exactly as you describe:
pcscddoesn't drive readers, ccid does, and that driver binds only USB ids present in its own list.0x1209:0x0001isn't in it, so the CCID interface is skipped silently — FIDO keeps working and every applet just looks absent rather than broken. No udev or polkit change can help, because both govern access to a reader the driver never claimed in the first place.The docs were actively misleading here, not merely incomplete: they said CCID needed "the extra two pieces below" (polkit,
disable-ccid) — and neither of those was the piece that was actually missing.On upstreaming to ccid — not yet, and deliberately
0x1209:0x0001is pid.codes' shared prototype id, not an allocation to this project. Adding it to the ccid reader list would bind every unrelated prototype using that same id, which isn't mine to do. A dedicated VID/PID is pending; the submission goes in when it lands. I've put that reason into the docs so the next person gets an explanation instead of silence.Docs fixed
docs/linux.mdnow leads with the reader list before the setup steps, and documents both routes:- the source-side
supported_readers.txtline (yours — credited to this issue); - the
Info.plistedit for FHS distros, with the warning thatifdVendorID/ifdProductID/ifdFriendlyNameare three parallel arrays, so an entry has to go into each at the same index or the mapping shifts.
On the nix patch and the overlay
I'd rather not carry those in this repo. They'd bake the prototype id into the firmware tree, and they fix the symptom for one distro's packaging while the actual fix is the allocation. Documented workaround now, upstream submission once the id exists. Keeping your overlay in your own config is the pragmatic answer meanwhile — and thank you for confirming it works end to end.
If you just want it working today
Build
VIDPID=Yubikey5. That identity is already in the ccid list, and the stock yubico udev rules cover it unchanged — which is also why this never showed up on my own bench, since that's the build I run.Leaving this open until the VID/PID lands and the upstream submission is in.
- the source-side
Thanks for documenting this and fixing the misleading part in the docs. I just wanted to add some additional context regarding the possibility of getting a dedicated PID from pid.codes.
Personally, I think obtaining a dedicated PID may be challenging for RS-Key at the current stage (although it is certainly still worth trying in the future).
My reasoning comes from the requirements described in the pid.codes application guide:
If your project involves both hardware and software, both need to be licensed under recognised OSS and OSHW licenses. If your project involves only one or the other, we may ask for further justification as to why you need a PID associated with your software project / development board instead of allowing end-users to request their own.
This seems to suggest that pid.codes generally expects a PID to represent a specific product identity — for example, a particular open hardware design together with its firmware/software.
However, RS-Key is currently primarily a software/firmware project. It does not yet have its own open hardware design; instead, it provides firmware and software support for multiple existing development boards. Because of this, it may be difficult to demonstrate that the PID represents a distinct hardware product identity rather than a software project that can run on different third-party boards.
Of course, this situation could change if RS-Key eventually develops its own dedicated open hardware design. At that point, applying for a dedicated PID would make much more sense, since the VID/PID pair could represent a specific open hardware product (i.e. a specific device model in practical terms).
This is just my interpretation of the pid.codes requirements, and hopefully it provides some additional context for the decision.
CC @TheMaxMur and thanks for those amazing works.
Reacted by MaxMurReacted by MaxMurI'm currently trying to track down a bug in webauthn on a specific environment. I need some time, it's very difficult and takes a long time to reproduce, so please wait until I make a fix and the updated documentation appears in the new release. Thanks for the feedback.
Reacted by CuriousReacted by CuriousMmmh, didn't search discussions, just issues, so didn't see any of them :-/ will look there next time, before going down the rabbit hole.
0x1209:0x0001is pid.codes' shared prototype idOh I see, fair enough, useful to know.
On the nix patch and the overlay
That was the very reason I didn't provide, as it could get messy. Happy to share though if needed later, albeit it's simple.
If you just want it working today
My local patch does seem to work, so no need to fake a YubiKey.
which is also why this never showed up on my own bench, since that's the build I run.
Are there any gotchas you can think of by sticking with the temporary rs-key VID/PID pair and then updating later?
so, any update?
This seems to suggest that pid.codes generally expects a PID to represent a specific product identity — for example, a particular open hardware design together with its firmware/software.
pidcodes/pidcodes.github.com#1226
In general, you're right; you can follow the discussion of pid.codes here.
JFYI @Curious-r
Reacted by CuriousReacted by CuriousThis seems to suggest that pid.codes generally expects a PID to represent a specific product identity — for example, a particular open hardware design together with its firmware/software.
pidcodes/pidcodes.github.com#1226
In general, you're right; you can follow the discussion of pid.codes here.
JFYI @Curious-r
It's time to use a new VID/PID. 🥰
Before filing
main.Area
Build / nix / flashing
Firmware build
fw 5.7.4 built from source for 16m device
Board
TENSTAR RP2350-USB 16MB
Host environment
nix
What happened
The ccid driver does not list by default the RS-Key identity 0x1209:0x0001. This makes pcscd skip the CCID interface and all the goodness that goes with that.
Suggested changes:
as existing SoloKeys Solo 2 + F-Secure USB Armory entries.
Could;
These are not ideal, so you might want to do things differently.
Ideally the device would get added upstream to ccid, to include your device, but that is up to you.
Tested ccid 1.7.1. Patch context-anchored on SoloKeys entry, refresh if ccid
reorder list.
Purely additive, no behaviour change for current users.
Steps to reproduce
Follow the docs for configuring the device and when you get to the 'it just works', insert this step and then it worked for me.
As soon as the ccid entry was added, the applets lit up and the tui was fully populated for all the applets.
Output / logs
Anything else
No response