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-4600GitHub issuePublicReceived

Lock screen can expose password text after failed authentication

Reported by evo-social-world · filed Aug 15, 2026Closed upstream on 2026-08-15 by dhh, as a duplicate of #6858 (R-1866). GitHub close reason: not_planned.

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

Lock screen can expose password text after failed authenticationrevision 1 · captured 2026-10-04 12:03 UTC via poll

System details

AMD Ryzen 9 9950X3D, NVIDIA GeForce RTX 5090 D, Omarchy 4.0.0-1 (stable), kernel 7.1.7-arch1-1, Hyprland 0.56.2-1, quickshell-git 0.3.0.r20.g28771c7-1, Qt 6.11.1, fcitx5 5.1.21 with Rime.

What's wrong?

On Quattro's Quickshell lock screen, password masking can fail after an unsuccessful authentication attempt. The first attempt is shown as dots. After PAM reports Authentication failed, typing the next attempt can render the actual characters instead of dots. The password still authenticates, so this is a credential-disclosure issue rather than only a visual glitch.

Steps reproduced on this machine:

  1. Run omarchy system lock or wait for the idle lock.
  2. Enter an intentionally wrong password and press Enter.
  3. Wait for Authentication failed (1).
  4. Type the next password attempt.
  5. The field may show the typed characters in clear text instead of password dots.

Expected: every attempt remains masked, including after any number of PAM failures.

The journal confirms the reported sequence in the Quickshell lock service: two failed omarchy-lock-password PAM sessions followed by a successful one. There were no QML property errors around the failures.

This does not appear to be a local Omarchy customization:

  • pacman -Qkk omarchy reports 1628 total files, 0 altered files.
  • There is no user clone/override of omarchy.lock.
  • ~/.config/omarchy/shell.json only changes bar layout and idle timings.
  • The installed LockView.qml is identical to the quattro branch.

Investigation points to the post-authentication focus/input lifecycle rather than the normal Qt password renderer:

  • LockView.qml hard-codes echoMode: TextInput.Password and passwordMaskDelay: 0.
  • A Qt 6.11.1 isolation test keeps displayText fully masked across the same enabled/readOnly transition.
  • Instantiating Omarchy's exact packaged LockView.qml and simulating the failed-auth transition also keeps echoMode=Password and displayText masked, but leaves the password input with activeFocus=false after authentication finishes.
  • That lost-focus result matches the independently reported lock-screen focus bug in #6858. On this system the shell also uses Fcitx/Rime, so an input-method/preedit path after focus loss is a plausible contributor, but that part is not yet proven.

Security-hardening suggestion:

  1. Re-arm password focus whenever authenticatingPassword changes back to false, as discussed in #6858.
  2. Use TextInput.NoEcho and render password dots separately from passwordText.length, so neither Qt password echo nor input-method preedit can ever render clear text.
  3. Add a graphical regression test covering failed PAM -> refocus -> second attempt, ideally with an input method active.

Related: #6858

View raw text
### System details

AMD Ryzen 9 9950X3D, NVIDIA GeForce RTX 5090 D, Omarchy 4.0.0-1 (stable), kernel 7.1.7-arch1-1, Hyprland 0.56.2-1, quickshell-git 0.3.0.r20.g28771c7-1, Qt 6.11.1, fcitx5 5.1.21 with Rime.

### What's wrong?

On Quattro's Quickshell lock screen, password masking can fail after an unsuccessful authentication attempt. The first attempt is shown as dots. After PAM reports `Authentication failed`, typing the next attempt can render the actual characters instead of dots. The password still authenticates, so this is a credential-disclosure issue rather than only a visual glitch.

Steps reproduced on this machine:

1. Run `omarchy system lock` or wait for the idle lock.
2. Enter an intentionally wrong password and press Enter.
3. Wait for `Authentication failed (1)`.
4. Type the next password attempt.
5. The field may show the typed characters in clear text instead of password dots.

Expected: every attempt remains masked, including after any number of PAM failures.

The journal confirms the reported sequence in the Quickshell lock service: two failed `omarchy-lock-password` PAM sessions followed by a successful one. There were no QML property errors around the failures.

This does not appear to be a local Omarchy customization:

- `pacman -Qkk omarchy` reports `1628 total files, 0 altered files`.
- There is no user clone/override of `omarchy.lock`.
- `~/.config/omarchy/shell.json` only changes bar layout and idle timings.
- The installed `LockView.qml` is identical to the `quattro` branch.

Investigation points to the post-authentication focus/input lifecycle rather than the normal Qt password renderer:

- `LockView.qml` hard-codes `echoMode: TextInput.Password` and `passwordMaskDelay: 0`.
- A Qt 6.11.1 isolation test keeps `displayText` fully masked across the same enabled/readOnly transition.
- Instantiating Omarchy's exact packaged `LockView.qml` and simulating the failed-auth transition also keeps `echoMode=Password` and `displayText` masked, but leaves the password input with `activeFocus=false` after authentication finishes.
- That lost-focus result matches the independently reported lock-screen focus bug in #6858. On this system the shell also uses Fcitx/Rime, so an input-method/preedit path after focus loss is a plausible contributor, but that part is not yet proven.

Security-hardening suggestion:

1. Re-arm password focus whenever `authenticatingPassword` changes back to false, as discussed in #6858.
2. Use `TextInput.NoEcho` and render password dots separately from `passwordText.length`, so neither Qt password echo nor input-method preedit can ever render clear text.
3. Add a graphical regression test covering failed PAM -> refocus -> second attempt, ideally with an input method active.

Related: #6858

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.