Proof Portal
Omarchy
ProbeLabsviewing a historical runA 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.
Non-positive sleep-lock budget for logind windows <= 1s: suspend proceeds with no lock attempt
Medium-severity issue, currently open.
Description
The issue as recorded.
derive_budget_ms reserves max(window/5, 1000ms) with no floor (bin/omarchy-system-sleep-lock:37-40): a 1s InhibitDelayMaxUSec yields budget 0 and any sub-second window yields a NEGATIVE budget. The line-45 heal guard re-derives instead of flooring - a second identical busctl read that reinstalls the same illegal value. With budget <= 0 the deadline is already past, so every lock_ipc hits the remaining<=0 guard and returns 1 with empty stdout. request_lock's case then silently falls through. The machine suspends with the lock NEVER attempted - only a 'within 0ms' notification marks it.
Affected requirements
The requirement(s) this issue violates — click through to the spec.
Severity, explained
Why this is rated the way it is — and the scoring signals behind the rating (each ⓘ explains the term).
- why this rating
- Risk-rated
- risk area
- Correctness
- CVE surface
- None
How it's proven
The reproducer — an actual test that drives the real code and shows the issue happening. Run it yourself, or peek the test and the source it covers.
./pocs/crs-260930-gzq0-c01-c02-c10.sh
Reproduction steps
Technical steps for your engineers to confirm the issue by hand.
./pocs/crs-260930-gzq0-c01-c02-c10.sh
What protects you, and the fix
What limits your exposure today, and the planned remediation.
What protects you now
default 5s window stays unaffected; only logind drop-ins with windows <= 1s hit the chain
The fix
Floor the derived budget at 1ms (or clamp the reserve to window-1ms). Make the heal guard substitute a safe constant instead of re-deriving. Surface lock_ipc's refusal instead of swallowing it
Blast radius
If you touch this issue, what else may need re-checking — the requirements it affects and the code and tests that hang off them. Historical view: authored trace links only — automatically derived links aren't reconstructible for past runs.
Touch this finding and you re-check 1 requirements · 1 code files · 1 tests.
- omarchy-system-sleep-lock
- sleep-lock-test.sh
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Per-requirement evidence
For each requirement this finding touches: the implementing code, verifying tests, and proof obligations that discharge it.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
Evidence trail
The raw evidence manifests behind this finding — superseded by the resolved reproducer above, kept here for traceability.
- proof/evidence/ki-sleep-lock-budget-nonpositive.yaml
Change history
Every recorded revision of this finding's source file — when it was added, edited, or re-classified, with the diff for each change.
Discussions
Discuss this with the proof team. Nothing changes in your audit automatically — you open a request and a staff member records any outcome inside the thread.