Proof Portal

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

Enterprise wifi login (Quattro shell widget) hardcodes 8s 802-1x.auth-timeout and sets no CA cert, causing false auth failures

Reported by skrilexxx · filed Sep 17, 2026 · open at source

Decided: Out of scope — decided by agents · verified 4 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

Enterprise wifi login (Quattro shell widget) hardcodes 8s 802-1x.auth-timeout and sets no CA cert, causing false auth failuresrevision 1 · captured 2026-09-28 21:23 UTC via poll

What happened

Logging into a WPA-Enterprise (802.1X/PEAP-MSCHAPv2) network through the Quattro network panel's login dialog reliably fails with what looks like a wrong password, even when the credentials are correct.

Root cause: shell/plugins/panels/network/Model.js builds the enterprise connection profile with a script (enterpriseConnectScript, around line 319-324) that runs:

nmcli connection add ... wifi-sec.key-mgmt wpa-eap 802-1x.eap peap 802-1x.phase2-auth mschapv2 802-1x.identity "$2" 802-1x.auth-timeout 8

Two problems with this generated profile:
1. 802-1x.auth-timeout 8 hardcodes an 8-second EAP timeout. On networks where the full handshake (association + EAP + WPA 4-way handshake) takes a little longer than 8s, wpa_supplicant/NetworkManager aborts the connection right as/after EAP succeeds. The user sees a generic auth failure indistinguishable from a wrong password.
2. No 802-1x.ca-cert (or 802-1x.domain-suffix-match/802-1x.domain-match) is set, so the generated profile has no server-certificate validation at all, unlike a profile created through a proper onboarding flow (e.g. an institution's eduroam CAT installer).

Steps to reproduce

  1. On Omarchy Quattro (4.0.4-1), open the network panel and log into any WPA-Enterprise (PEAP/MSCHAPv2) SSID with correct credentials, on a network/AP combo where the full handshake takes close to or more than 8 seconds.
  2. Observe journalctl -u NetworkManager / journalctl output: CTRL-EVENT-EAP-SUCCESS appears, followed almost exactly 8 seconds after CTRL-EVENT-EAP-STARTED by a locally-generated deauth (reason=3) and NetworkManager reporting the connection failed with no-secrets.
  3. The panel reopens the passphrase prompt as if the password were wrong (needsCredentials/NoSecrets handling around Model.js:330-347), even though EAP authentication itself succeeded every time.

Expected

  • The generated connection profile should use NetworkManager's default 802-1x.auth-timeout (0, meaning use the driver/supplicant default) instead of hardcoding 8 seconds, since 8s is too short for some real-world enterprise networks.
  • The profile should support setting a CA certificate / domain match when the network requires or benefits from it, matching what a real onboarding flow (e.g. eduroam CAT) configures, instead of skipping certificate validation entirely.

System

  • Omarchy version: 4.0.4-1
  • Confirmed via journalctl logs showing EAP-MSCHAPv2 authentication succeeding, then a locally-generated disconnect almost exactly 8 seconds after EAP started, matching the hardcoded 802-1x.auth-timeout 8 in enterpriseConnectScript.
  • Workaround: manually create/edit the 802-1x connection profile via nmcli with 802-1x.auth-timeout 0 (or higher) and a proper 802-1x.ca-cert, bypassing the network panel's enterprise login dialog.
View raw text
## What happened

Logging into a WPA-Enterprise (802.1X/PEAP-MSCHAPv2) network through the Quattro network panel's login dialog reliably fails with what looks like a wrong password, even when the credentials are correct.

Root cause: `shell/plugins/panels/network/Model.js` builds the enterprise connection profile with a script (`enterpriseConnectScript`, around line 319-324) that runs:

```
nmcli connection add ... wifi-sec.key-mgmt wpa-eap 802-1x.eap peap 802-1x.phase2-auth mschapv2 802-1x.identity "$2" 802-1x.auth-timeout 8
```

Two problems with this generated profile:
1. `802-1x.auth-timeout 8` hardcodes an 8-second EAP timeout. On networks where the full handshake (association + EAP + WPA 4-way handshake) takes a little longer than 8s, `wpa_supplicant`/`NetworkManager` aborts the connection right as/after EAP succeeds. The user sees a generic auth failure indistinguishable from a wrong password.
2. No `802-1x.ca-cert` (or `802-1x.domain-suffix-match`/`802-1x.domain-match`) is set, so the generated profile has no server-certificate validation at all, unlike a profile created through a proper onboarding flow (e.g. an institution's eduroam CAT installer).

## Steps to reproduce

1. On Omarchy Quattro (4.0.4-1), open the network panel and log into any WPA-Enterprise (PEAP/MSCHAPv2) SSID with correct credentials, on a network/AP combo where the full handshake takes close to or more than 8 seconds.
2. Observe `journalctl -u NetworkManager` / `journalctl` output: `CTRL-EVENT-EAP-SUCCESS` appears, followed almost exactly 8 seconds after `CTRL-EVENT-EAP-STARTED` by a locally-generated deauth (`reason=3`) and NetworkManager reporting the connection failed with `no-secrets`.
3. The panel reopens the passphrase prompt as if the password were wrong (`needsCredentials`/`NoSecrets` handling around Model.js:330-347), even though EAP authentication itself succeeded every time.

## Expected

- The generated connection profile should use NetworkManager's default `802-1x.auth-timeout` (0, meaning use the driver/supplicant default) instead of hardcoding 8 seconds, since 8s is too short for some real-world enterprise networks.
- The profile should support setting a CA certificate / domain match when the network requires or benefits from it, matching what a real onboarding flow (e.g. eduroam CAT) configures, instead of skipping certificate validation entirely.

## System

- Omarchy version: 4.0.4-1
- Confirmed via `journalctl` logs showing EAP-MSCHAPv2 authentication succeeding, then a locally-generated disconnect almost exactly 8 seconds after EAP started, matching the hardcoded `802-1x.auth-timeout 8` in `enterpriseConnectScript`.
- Workaround: manually create/edit the 802-1x connection profile via `nmcli` with `802-1x.auth-timeout 0` (or higher) and a proper `802-1x.ca-cert`, bypassing the network panel's enterprise login dialog.

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 14:47 UTC