The vendor-ID guess rejects any device with a driver bound, on the
reasoning that libfprint drives readers from userspace so a real one sits
there unbound. But libusb claims interfaces through a synthetic usbfs
driver, so the reader binds one for as long as fprintd holds the claim —
which is exactly while it is being enrolled or verified against.
Readers that name themselves take the product-string branch and never
reach this, so the exposure is the ones that don't: Goodix 27c6:6594
reports "Goodix USB2.0 MISC", matches on vendor ID alone, and drops out
of detection mid-authentication. The menu entry disappears and the
first-run invitation stops firing while the reader is in use.
Ignore a driver link that resolves to usbfs, and keep rejecting the real
ones — usbio-bridge, usbhid, uvcvideo — including on a device that has
both.
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Restore FPC fingerprint detection
* Anchor the FPC product match to a prefix
*fpc* is an unanchored three-letter token on the one branch that is
trusted outright, with none of the kernel-driver checking the vendor
guess gets. Every FPC reader on record leads with it — "FPC Sensor
Controller", "FPC Sensor Controller L:0002 FW:25.26.23.14", and this
branch's "FPC L:0000 FW:1425046" — so requiring the prefix costs no
coverage while keeping three letters from matching mid-string, where
FPC abbreviates unrelated things like flexible printed circuit.
Also restore the note about why Elan is kept out of the vendor list, so
the two signatures read as the same deliberate exception.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Write no product descriptor for a two-field device spec
${remainder#*:} returns the string unchanged when there is no second
colon, so a spec meant to describe a device with no product descriptor
wrote the product id out as its product string instead. Every call site
happened to pass a trailing colon, so the suite was right by accident.
Guard the split and drop the trailing colons, so the two vendor-match
cases exercise the path they were written for.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Bind a named driver in the kernel-driver fixture
Touching a bare `driver` file asserts that any driver at all disqualifies
a vendor guess, which is more than the detector should promise: libusb
claims an interface through a synthetic `usbfs` driver, so a reader in
active use looks bound by that rule.
Link the interface at a named driver directory instead, the way sysfs
does. The case still covers what it was written for — a Synaptics bridge
or a camera on a fingerprint vendor ID — without fixing the shape of the
answer for drivers it was never about.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Detect Elan match-on-chip fingerprint readers again
Elan readers report "ELAN:ARM-M4" as their product string, so the
*fingerprint* and *biometric* checks miss them. Elan's 04f3 is also left
out of the vendor list on purpose, because Elan makes touchscreens too.
Both checks fail, so the machine looks like it has no reader.
Add "elan:arm-m4" to the product string check. The comment above the
vendor list already says the excluded vendors should still match there,
so this makes that true. The vendor list and its has_kernel_driver guard
are unchanged, and touchscreens still cannot cause a false positive.
The string is a family name, not one device. libfprint uses it for
04f3:0c9c and 04f3:0ca7 as well as 04f3:0ca8.
Tested on an HP EliteBook X G2i with 04f3:0ca8.
* Point the Elan comment at the vendor list above it
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* Configure PAM only after a fingerprint enrolls and verifies
Detection proves a reader is present, not that libfprint can drive it.
Elan MOC sensors outside the elanmoc table pass the gate and then fail
to enroll, which left pam_fprintd in the sudo and polkit stacks with no
print to match.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: David Heinemeier Hansson <david@hey.com>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
A Dell XPS 14 with no fingerprint reader was invited to set one up on first
run. Its Synaptics webcam bridge, 06cb:0701 "SVP7500" bound to usbio-bridge,
matched omarchy-hw-fingerprint on the bare 06cb vendor ID.
The vendor list already excludes Elan and STMicro for being multi-purpose, but
Synaptics is just as multi-purpose and was left in. Dropping 06cb is not an
option: Synaptics and Validity are among the most common real reader vendors,
and many of those readers report no product string at all, so the vendor ID is
the only signal that finds them.
The vendor guess is now qualified instead. libfprint drives every reader it
supports from userspace over libusb, so a real reader sits with no kernel
driver bound to any of its interfaces, while the bridges, touchpads and cameras
that share these vendor IDs all bind one. The guard applies only to the fuzzy
vendor-ID path; a device whose product descriptor names it a fingerprint reader
is still trusted outright, since that signal is precise enough on its own and
should not be lost to a driver that happened to claim the device.
The menu entry was a second surface for the same bug. Setup > Security >
Fingerprint carried no when clause, unlike the Remove entry beside it, so it
appeared on every machine and dead-ended in the setup script's own hardware
check. It now gates on the same detector.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017q97Rsk8KwgaPUVq5ArLgM
Add a first-run notification, alongside the keybindings/Wi-Fi toasts, that
invites anyone with a fingerprint sensor to enable it. Clicking launches
omarchy-setup-security-fingerprint in a floating terminal.
Detection lives in a new omarchy-hw-fingerprint helper that reads sysfs
(device product descriptor plus a fingerprint-vendor allowlist), so it
works before fprintd/usbutils are installed and without nagging machines
that have no reader. The setup script reuses the same helper as an early
gate, bailing before installing any packages when no reader is found
(replacing the old post-install fprintd-list probe).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
