Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A 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.

Inbox
ReportR-4643GitHub issuePublicReceived

Fingerprint setup misses Broadcom BCM58200 ControlVault 3 (vendor 0a5c not in detection list)

Reported by bartcho · filed Aug 21, 2026Closed upstream on 2026-09-21 by bjarneo via an automated message, as a duplicate of #7424 (R-1672). GitHub close reason: completed.

Open at source
Received and recorded verbatim. Nothing has been checked yet.

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

Fingerprint setup misses Broadcom BCM58200 ControlVault 3 (vendor 0a5c not in detection list)revision 1 · captured 2026-10-04 12:03 UTC via poll

Summary

omarchy setup security fingerprint aborts with "No fingerprint sensor detected" even though a supported reader is present. The hardware check hard-codes a vendor allow-list that omits Broadcom (0a5c), which is the vendor for the BCM58200 ControlVault 3 fingerprint reader found in many Dell Latitude/Precision laptops.

Steps to reproduce

  1. Machine with a Broadcom BCM58200 ControlVault 3 reader (USB 0a5c:5843).
  2. Run omarchy setup security fingerprint.
  3. Output: Setting up fingerprint scanner for authentication. -> No fingerprint sensor detected. and the wizard exits before installing fprintd or touching PAM.

Expected

The reader is detected and setup proceeds (install fprintd, enroll, verify, configure PAM).

Root cause

The hidden helper /usr/share/omarchy/bin/omarchy-hw-fingerprint only matches these USB vendor IDs:

fingerprint_vendors=" 27c6 138a 06cb 08ff 1c7a 147e "

Broadcom's vendor 0a5c is absent. Two details that make this a clean, low-risk fix:

  • The device's sysfs product string is just 58200 (the "(FingerPrint sensor + Contacted SmartCard)" text shown by lsusb comes from the usb.ids database, not the device), so the product-name match (*fingerprint* / *biometric* / *elan:arm-m4* / fpc *) doesn't catch it either.
  • No kernel driver is bound to the device (all 4 interfaces are unbound), so the has_kernel_driver guard is already satisfied. Adding `0a5c` to the vendor list is sufficient for detection to pass.

Confirmed hardware on the affected machine:

Bus 003 Device 003: ID 0a5c:5843 Broadcom Corp. BCM58200 ControlVault 3 (FingerPrint sensor + Contacted SmartCard)

This reader is driven by the libfprint-tod (TOD) driver: libfprint-tod-git ships /usr/lib/libfprint-2/tod-1/libfprint-2-tod-1-broadcom.so, and fprintd-enroll / fprintd-verify succeed against /net/reactivated/Fprint/Device/0.

Related issue in the wizard

Even with detection fixed, omarchy-setup-security-fingerprint installs stock libfprint (omarchy-pkg-add libfprint fprintd usbutils) and only removes libfprint-git — not libfprint-tod-git. On machines whose reader needs the TOD driver, installing stock libfprint conflicts with the already-installed libfprint-tod-git (which provides+conflicts libfprint), so the package step would fail. The wizard should account for the TOD driver (detect it / prefer it / remove libfprint-tod-git like it does libfprint-git).

Suggested fix

  1. Add 0a5c (Broadcom) to fingerprint_vendors in omarchy-hw-fingerprint.
  2. In omarchy-setup-security-fingerprint, also remove libfprint-tod-git before omarchy-pkg-add libfprint, mirroring the existing libfprint-git handling — or, better, detect when the matched reader requires the TOD driver and install libfprint-tod-git + fprintd instead of stock libfprint.

Workaround used locally (for reference)

Install fprintd while keeping libfprint-tod-git, enroll with sudo fprintd-enroll "$USER", verify with fprintd-verify, then add pam_fprintd.so (+ the omarchy-hw-laptop-closed clamshell gate) to /etc/pam.d/sudo and /etc/pam.d/polkit-1, and create /etc/pam.d/omarchy-lock-fingerprint. This works fully.

System

  • Omarchy 4.0.0-1
  • Arch Linux, Hyprland
  • Reader: Broadcom BCM58200 ControlVault 3 (0a5c:5843)
View raw text
## Summary
`omarchy setup security fingerprint` aborts with "No fingerprint sensor detected" even though a supported reader is present. The hardware check hard-codes a vendor allow-list that omits Broadcom (`0a5c`), which is the vendor for the BCM58200 ControlVault 3 fingerprint reader found in many Dell Latitude/Precision laptops.

## Steps to reproduce
1. Machine with a Broadcom BCM58200 ControlVault 3 reader (USB `0a5c:5843`).
2. Run `omarchy setup security fingerprint`.
3. Output: `Setting up fingerprint scanner for authentication.` -> `No fingerprint sensor detected.` and the wizard exits before installing `fprintd` or touching PAM.

## Expected
The reader is detected and setup proceeds (install fprintd, enroll, verify, configure PAM).

## Root cause
The hidden helper `/usr/share/omarchy/bin/omarchy-hw-fingerprint` only matches these USB vendor IDs:

```
fingerprint_vendors=" 27c6 138a 06cb 08ff 1c7a 147e "
```

Broadcom's vendor `0a5c` is absent. Two details that make this a clean, low-risk fix:

- The device's sysfs product string is just `58200` (the "(FingerPrint sensor + Contacted SmartCard)" text shown by `lsusb` comes from the usb.ids database, not the device), so the product-name match (`*fingerprint*` / `*biometric*` / `*elan:arm-m4*` / `fpc *`) doesn't catch it either.
- No kernel driver is bound to the device (all 4 interfaces are unbound), so the `has_kernel_driver` guard is already satisfied. **Adding `0a5c` to the vendor list is sufficient for detection to pass.**

Confirmed hardware on the affected machine:
```
Bus 003 Device 003: ID 0a5c:5843 Broadcom Corp. BCM58200 ControlVault 3 (FingerPrint sensor + Contacted SmartCard)
```
This reader is driven by the `libfprint-tod` (TOD) driver: `libfprint-tod-git` ships `/usr/lib/libfprint-2/tod-1/libfprint-2-tod-1-broadcom.so`, and `fprintd-enroll` / `fprintd-verify` succeed against `/net/reactivated/Fprint/Device/0`.

## Related issue in the wizard
Even with detection fixed, `omarchy-setup-security-fingerprint` installs stock `libfprint` (`omarchy-pkg-add libfprint fprintd usbutils`) and only removes `libfprint-git` — not `libfprint-tod-git`. On machines whose reader needs the TOD driver, installing stock `libfprint` conflicts with the already-installed `libfprint-tod-git` (which provides+conflicts `libfprint`), so the package step would fail. The wizard should account for the TOD driver (detect it / prefer it / remove `libfprint-tod-git` like it does `libfprint-git`).

## Suggested fix
1. Add `0a5c` (Broadcom) to `fingerprint_vendors` in `omarchy-hw-fingerprint`.
2. In `omarchy-setup-security-fingerprint`, also remove `libfprint-tod-git` before `omarchy-pkg-add libfprint`, mirroring the existing `libfprint-git` handling — or, better, detect when the matched reader requires the TOD driver and install `libfprint-tod-git` + `fprintd` instead of stock `libfprint`.

## Workaround used locally (for reference)
Install `fprintd` while keeping `libfprint-tod-git`, enroll with `sudo fprintd-enroll "$USER"`, verify with `fprintd-verify`, then add `pam_fprintd.so` (+ the `omarchy-hw-laptop-closed` clamshell gate) to `/etc/pam.d/sudo` and `/etc/pam.d/polkit-1`, and create `/etc/pam.d/omarchy-lock-fingerprint`. This works fully.

## System
- Omarchy 4.0.0-1
- Arch Linux, Hyprland
- Reader: Broadcom BCM58200 ControlVault 3 (`0a5c:5843`)

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.