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-660GitHub issuePublicDecided· Out of scope

omarchy-hw-fingerprint false negative: FocalTech readers (2808:*) report as "no sensor"

Reported by alanwcurry-dev · filed Sep 11, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

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?
AreaOutside the audited area· Decided by agents · verified
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?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

omarchy-hw-fingerprint false negative: FocalTech readers (2808:*) report as "no sensor"revision 1 · captured 2026-09-28 21:23 UTC via poll

System details: ASUS ExpertBook PM3406CKA (AMD Ryzen AI 7 350 w/ Radeon 860M), Omarchy 4.0.3-1, kernel 7.2.3-arch1-3, BIOS PM3406CKA.304. Full omarchy-debug log: https://logs.omarchy.org/VHb4vx

What's wrong?

omarchy setup security fingerprint aborts with "No fingerprint sensor detected." on this laptop, even though the reader is present and works.

omarchy-hw-fingerprint exits 1 here. The reader:

  • is USB 2808:a57a, manufacturer Focal, product string FocalTech FT9365 ESS
  • binds no kernel driver on its single interface (class dc/a0/b0) — the userspace/libusb shape libfprint readers have, which is exactly what the script's has_kernel_driver check is built around
  • is driven fine by the pinned libfprint-git 1:1.94.100.r10.g6f9479c-1 ("pinned upstream snapshot with FocalTech and Synaptics 06cb:010b support"); upstream lists 2808:a57a as "Focaltech MOC Sensors"

Both detection paths in /usr/bin/omarchy-hw-fingerprint miss it:

  • fingerprint_vendors is 27c6 138a 06cb 08ff 1c7a 147e — FocalTech's 2808 is not in the list
  • the product-string match requires fingerprint / biometric / elan:arm-m4 / a leading fpc — FocalTech FT9365 ESS contains none of those

Because the wizard bails before installing anything, pacman -Q fprintd libfprint is empty afterwards, so the machine looks like it has no sensor at all. The same detector also gates setup-fingerprint.hook, so affected machines never get the post-update "Setup Fingerprint Reader" invitation either.

Steps to reproduce

  1. omarchy-hw-fingerprint; echo $? → 1 (expected 0)
  2. omarchy setup security fingerprint → "No fingerprint sensor detected.", exit 1
  3. Re-run with the detection gate bypassed through the script's own OMARCHY_USB_DEVICES_PATH seam:
mkdir -p /tmp/fpfake/dev1 && printf 'fingerprint\n' > /tmp/fpfake/dev1/product
OMARCHY_USB_DEVICES_PATH=/tmp/fpfake omarchy setup security fingerprint

That enrolls right-index-finger, gets verify-match from fprintd-verify, and writes /etc/pam.d/sudo, /etc/pam.d/polkit-1 and /etc/pam.d/omarchy-lock-fingerprint. Fingerprint auth then works end to end — sudo -k; sudo -v succeeds on a tap without a password, and pkexec true authenticates through the polkit-1 stack. Hardware, driver and PAM plumbing are all fine; only the presence test is wrong.

This is not specific to this one reader: the FocalTech MOC family is used across ASUS ExpertBook/Vivobook models and Samsung Galaxy Books (e.g. 2808:6553), so every one of them reads as "no sensor".

Suggested fix

Add 2808 to fingerprint_vendors. The has_kernel_driver check immediately below (with its usbfs exception) is what keeps multi-purpose vendors out, and it holds for FocalTech: their touchpads bind usbhid/i2c-hid — the touchpad on this machine is a separate ELAN 04f3:3340 i2c-hid device — while the fingerprint reader stays driverless. Alternatively match the product string on focaltech ft936* / focaltech moc if adding a whole vendor ID feels too broad.

View raw text
**System details:** ASUS ExpertBook PM3406CKA (AMD Ryzen AI 7 350 w/ Radeon 860M), Omarchy 4.0.3-1, kernel 7.2.3-arch1-3, BIOS PM3406CKA.304. Full `omarchy-debug` log: https://logs.omarchy.org/VHb4vx

### What's wrong?

`omarchy setup security fingerprint` aborts with "No fingerprint sensor detected." on this laptop, even though the reader is present and works.

`omarchy-hw-fingerprint` exits 1 here. The reader:

- is USB `2808:a57a`, manufacturer `Focal`, product string `FocalTech FT9365 ESS`
- binds no kernel driver on its single interface (class `dc`/`a0`/`b0`) — the userspace/libusb shape libfprint readers have, which is exactly what the script's `has_kernel_driver` check is built around
- is driven fine by the pinned `libfprint-git 1:1.94.100.r10.g6f9479c-1` ("pinned upstream snapshot with FocalTech and Synaptics 06cb:010b support"); upstream lists `2808:a57a` as "Focaltech MOC Sensors"

Both detection paths in `/usr/bin/omarchy-hw-fingerprint` miss it:

- `fingerprint_vendors` is `27c6 138a 06cb 08ff 1c7a 147e` — FocalTech's `2808` is not in the list
- the product-string match requires `fingerprint` / `biometric` / `elan:arm-m4` / a leading `fpc ` — `FocalTech FT9365 ESS` contains none of those

Because the wizard bails before installing anything, `pacman -Q fprintd libfprint` is empty afterwards, so the machine looks like it has no sensor at all. The same detector also gates `setup-fingerprint.hook`, so affected machines never get the post-update "Setup Fingerprint Reader" invitation either.

### Steps to reproduce

1. `omarchy-hw-fingerprint; echo $?` → `1` (expected `0`)
2. `omarchy setup security fingerprint` → "No fingerprint sensor detected.", exit 1
3. Re-run with the detection gate bypassed through the script's own `OMARCHY_USB_DEVICES_PATH` seam:

```bash
mkdir -p /tmp/fpfake/dev1 && printf 'fingerprint\n' > /tmp/fpfake/dev1/product
OMARCHY_USB_DEVICES_PATH=/tmp/fpfake omarchy setup security fingerprint
```

That enrolls right-index-finger, gets `verify-match` from `fprintd-verify`, and writes `/etc/pam.d/sudo`, `/etc/pam.d/polkit-1` and `/etc/pam.d/omarchy-lock-fingerprint`. Fingerprint auth then works end to end — `sudo -k; sudo -v` succeeds on a tap without a password, and `pkexec true` authenticates through the polkit-1 stack. Hardware, driver and PAM plumbing are all fine; only the presence test is wrong.

This is not specific to this one reader: the FocalTech MOC family is used across ASUS ExpertBook/Vivobook models and Samsung Galaxy Books (e.g. `2808:6553`), so every one of them reads as "no sensor".

### Suggested fix

Add `2808` to `fingerprint_vendors`. The `has_kernel_driver` check immediately below (with its `usbfs` exception) is what keeps multi-purpose vendors out, and it holds for FocalTech: their touchpads bind `usbhid`/`i2c-hid` — the touchpad on this machine is a separate ELAN `04f3:3340` i2c-hid device — while the fingerprint reader stays driverless. Alternatively match the product string on `focaltech ft936*` / `focaltech moc` if adding a whole vendor ID feels too broad.

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.

  • Out of scopeDecided by agents · verified · 2026-10-09 12:02 UTC