macOS release binary appears to require Homebrew libusb at runtime after 1.16.0 #346
Closed
TyceHerrman
started this conversation in
General
Replies: 1 comment
|
Opened a draft approach in #348 — it replaces Not sure yet if this is the right direction — wanted to get it up for discussion. The FIDO2 provider was already fine ( This comment was generated by Claude Code. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
I’m seeing what looks like a macOS runtime-linking issue with the released fnox binary.
I installed fnox via mise, and the binary fails to start because dyld cannot find:
/opt/homebrew/opt/libusb/lib/libusb-1.0.0.dylib
otool -L on the installed binary shows that exact dylib path as a runtime dependency.
Possible explanation:
v1.16.0 added ctap-hid-fido2 and yubico_manager to fnox’s main dependencies. Those are hardware-token crates,: ctap-hid-fido2 documents a libusb-1.0 dependency on some platforms, and the YubiKey challenge-response crate lineage derived from yubico_manager documents that the default rusb backend depends on libusb, while nusb exists specifically to avoid libusb. Since rusb is a wrapper around native libusb, a macOS release binary in the 1.16.x line ending up linked to libusb would be consistent with the new FIDO2/YubiKey support added in that release series, even if that still does not by itself prove the exact packaging/linking path for the published binary.
Questions:
I can provide the exact dyld error and otool -L output if helpful.
Written with help from Codex
All reactions