Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
omarchy-hw-fingerprint doesn't detect Dell ControlVault 3 (Broadcom BCM58200, vendor 0a5c)
Reported by JeronimoColon · filed Aug 31, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7424 (R-1672). GitHub close reason: completed.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
What happened
omarchy-hw-fingerprint (and therefore omarchy setup security fingerprint) reports no fingerprint reader present on a Dell Latitude 5420, even though a Dell ControlVault 3 fingerprint sensor is physically present, correctly driven by libfprint-tod + the Dell-provided libfprint-2-tod1-broadcom driver, and successfully identified by fprintd:
$ fprintd-list jeronimocolon3
found 1 devices
Device at /net/reactivated/Fprint/Device/0
Using device /net/reactivated/Fprint/Device/0
User jeronimocolon3 has no fingers enrolled for Broadcom Sensors.
$ omarchy-hw-fingerprint; echo $?
1What was expected
omarchy-hw-fingerprint should detect this sensor so omarchy setup security fingerprint can proceed (installing packages / PAM config), instead of bailing out immediately with "No fingerprint sensor detected."
Root cause
Reading /usr/share/omarchy/bin/omarchy-hw-fingerprint: detection matches either a USB product-string keyword (fingerprint, biometric, elan:arm-m4, fpc ) or a vendor-ID allowlist (27c6 138a 06cb 08ff 1c7a 147e) combined with "no kernel driver bound."
The ControlVault 3 doesn't match either heuristic:
- USB vendor ID is 0a5c (Broadcom) — not in the allowlist.
- /sys/bus/usb/devices/*/product reports just "58200" — no "fingerprint"/"biometric" substring.
$ lsusb | grep -i broadcom
Bus 003 Device 003: ID 0a5c:5843 Broadcom Corp. BCM58200 ControlVault 3 (FingerPrint sensor + Contacted SmartCard)
$ cat /sys/bus/usb/devices/3-8/idVendor /sys/bus/usb/devices/3-8/idProduct /sys/bus/usb/devices/3-8/product /sys/bus/usb/devices/3-8/manufacturer
0a5c
5843
58200
Broadcom CorpNo kernel driver is bound to any of the device's interfaces (confirmed via sysfs), consistent with libfprint-tod driving it over libusb — so the vendor-ID heuristic's "no kernel driver" condition is satisfied; only the vendor allowlist itself is missing this ID.
Suggested fix
Add 0a5c (Broadcom) to fingerprint_vendors in omarchy-hw-fingerprint. Broadcom's ControlVault line is fingerprint/smartcard-specific (unlike Elan/STMicro, which the script's own comments note were deliberately left out for being multi-purpose), so it should be safe to allowlist outright the same way the other single-purpose vendors are.
System details
- Omarchy 4.0.1-1
- Dell Latitude 5420
- Kernel 7.1.9-arch1-2
- Sensor: Dell ControlVault 3, Broadcom BCM58200, USB ID
0a5c:5843 libfprint-tod1.95.2+tod1-1,libfprint-2-tod1-broadcom5.15.021.0-1,fprintd1.94.5-2
Note
This is a detection-only issue. There's a separate, currently open upstream bug in the libfprint-2-tod1-broadcom driver itself affecting enrollment reliability on this same hardware family: https://bugs.launchpad.net/libfprint-2-tod1-broadcom/+bug/2119302 — fixing detection here won't by itself make fingerprint auth reliable until that's resolved too, but it's a prerequisite for the setup wizard to even run.
View raw text
### What happened `omarchy-hw-fingerprint` (and therefore `omarchy setup security fingerprint`) reports no fingerprint reader present on a Dell Latitude 5420, even though a Dell ControlVault 3 fingerprint sensor is physically present, correctly driven by `libfprint-tod` + the Dell-provided `libfprint-2-tod1-broadcom` driver, and successfully identified by `fprintd`: ``` $ fprintd-list jeronimocolon3 found 1 devices Device at /net/reactivated/Fprint/Device/0 Using device /net/reactivated/Fprint/Device/0 User jeronimocolon3 has no fingers enrolled for Broadcom Sensors. $ omarchy-hw-fingerprint; echo $? 1 ``` ### What was expected `omarchy-hw-fingerprint` should detect this sensor so `omarchy setup security fingerprint` can proceed (installing packages / PAM config), instead of bailing out immediately with "No fingerprint sensor detected." ### Root cause Reading `/usr/share/omarchy/bin/omarchy-hw-fingerprint`: detection matches either a USB product-string keyword (`fingerprint`, `biometric`, `elan:arm-m4`, `fpc `) or a vendor-ID allowlist (`27c6 138a 06cb 08ff 1c7a 147e`) combined with "no kernel driver bound." The ControlVault 3 doesn't match either heuristic: - USB vendor ID is `0a5c` (Broadcom) — not in the allowlist. - `/sys/bus/usb/devices/*/product` reports just `"58200"` — no "fingerprint"/"biometric" substring. ``` $ lsusb | grep -i broadcom Bus 003 Device 003: ID 0a5c:5843 Broadcom Corp. BCM58200 ControlVault 3 (FingerPrint sensor + Contacted SmartCard) $ cat /sys/bus/usb/devices/3-8/idVendor /sys/bus/usb/devices/3-8/idProduct /sys/bus/usb/devices/3-8/product /sys/bus/usb/devices/3-8/manufacturer 0a5c 5843 58200 Broadcom Corp ``` No kernel driver is bound to any of the device's interfaces (confirmed via sysfs), consistent with libfprint-tod driving it over libusb — so the vendor-ID heuristic's "no kernel driver" condition is satisfied; only the vendor allowlist itself is missing this ID. ### Suggested fix Add `0a5c` (Broadcom) to `fingerprint_vendors` in `omarchy-hw-fingerprint`. Broadcom's ControlVault line is fingerprint/smartcard-specific (unlike Elan/STMicro, which the script's own comments note were deliberately left out for being multi-purpose), so it should be safe to allowlist outright the same way the other single-purpose vendors are. ### System details - Omarchy 4.0.1-1 - Dell Latitude 5420 - Kernel 7.1.9-arch1-2 - Sensor: Dell ControlVault 3, Broadcom BCM58200, USB ID `0a5c:5843` - `libfprint-tod` 1.95.2+tod1-1, `libfprint-2-tod1-broadcom` 5.15.021.0-1, `fprintd` 1.94.5-2 ### Note This is a detection-only issue. There's a separate, currently open upstream bug in the `libfprint-2-tod1-broadcom` driver itself affecting enrollment reliability on this same hardware family: https://bugs.launchpad.net/libfprint-2-tod1-broadcom/+bug/2119302 — fixing detection here won't by itself make fingerprint auth reliable until that's resolved too, but it's a prerequisite for the setup wizard to even run.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.