[Bug 273596] Teach contrib/libfido2 to talk to hidraw(4) devices
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 273596] Teach contrib/libfido2 to talk to hidraw(4) devices"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 273596] Teach contrib/libfido2 to talk to hidraw(4) devices"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 273596] Teach contrib/libfido2 to talk to hidraw(4) devices"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 273596] Teach contrib/libfido2 to talk to hidraw(4) devices"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 06 Sep 2023 12:03:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273596
Bug ID: 273596
Summary: Teach contrib/libfido2 to talk to hidraw(4) devices
Product: Base System
Version: CURRENT
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: usb
Assignee: usb@FreeBSD.org
Reporter: dhorn2000@gmail.com
CC: emaste@freebsd.org
Flags: mfc-stable12?
Created attachment 244678
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=244678&action=edit
Patch to stable/14 for teaching libfido2 to enumeration hidraw(4) dev nodes
contrib/libfido2 in base (impacts -CURRENT + stable/14) is currently 1.10 and
does not support the hidraw(4) device enumeration properly, just the legacy
uhid(4) in the current tree.
Request update to latest libfido2 release (as of writing seems to be 1.13), and
eventual MFC to stable/14 at least.
My failcase is enabling hidraw devices via /boot/loader.conf, then attempting
to use base OpenSSH with the built-in SK provider to talk to a FIDO key (e.g.
Yubikey). This will fail by default as this version of libfido2 does not know
to look for the /dev/hidrawXX entries, just /dev/uhidYY device nodes.
Cherry picking just hid_freebsd.c with required changes from upstream will also
fix the issue, but probably best to get the full release.
https://raw.githubusercontent.com/Yubico/libfido2/f1a74c8f2792e269a0c47f156e13e6ddb457b1d3/src/hid_freebsd.c
From what I can tell, the contrib/libfido2 module installs as
libprivatefido2.a/libprivatefido2.so which means that users are unable to
workaround this limitation by just installing libfido2 from ports.
I'm glad to assist in testing this as either a patch, or in -CURRENT/stable
tree.
--
You are receiving this mail because:
You are the assignee for the bug.