Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA 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.
gnome-keyring silently recreated on every password-based SDDM login, orphaning all saved secrets
Reported by jandal · filed Sep 4, 2026Closed upstream on 2026-09-04 by its own reporter jandal. GitHub close reason: completed. Closed by its own reporter — not by itself evidence of a fix.
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
System: Omarchy 4.0.2-1, kernel 7.1.9-arch1-2
What happened:
Every time I restart and log in via SDDM with a password (not autologin), my entire GNOME Keyring is effectively wiped — saved app passwords, SSH agent unlock, etc. are all gone and I'm prompted to set a new keyring password as if for the first time.
Root cause (from journal + PAM inspection):
/usr/share/omarchy/install/login/sddm.sh intentionally strips pam_gnome_keyring.so from the auth stage of /etc/pam.d/sddm, keeping it only in the session stage (auto_start). The comment says this is to support a passwordless "Default keyring" design. But when a keyring that isn't the passwordless default already exists on disk (e.g. a normal login.keyring), gnome-keyring can no longer obtain the login password at the auth stage to unlock it, and fails:
gnome-keyring-daemon: keyring was in an invalid or unrecognized format: /home/<user>/.local/share/keyrings/login.keyring
sddm-helper: gkr-pam: couldn't unlock the login keyring.Rather than surfacing an error, it silently creates a brand new empty keyring (prompting for a new password via a GUI dialog) and abandons the old one. Repeated occurrences leave a pile of orphaned duplicate keyring files behind (Default_Keyring.keyring, Default_Keyring_1.keyring, login_1.keyring, etc. — 5+ generations accumulated on my machine).
Expected: Either the passwordless-default-keyring design should be applied consistently (no legacy password-protected keyring ever gets created/left behind to conflict with it), or the existing keyring should actually be unlocked rather than silently discarded.
Also noticed: omarchy debug --no-sudo --print (referenced in the contributing docs) doesn't exist as a command in 4.0.2-1 — omarchy commands --all has no debug or system stats-style diagnostics dump.
Steps to reproduce:
1. Fresh/aged Omarchy install where a login.keyring (or any non-"Default_keyring"-named keyring) exists in ~/.local/share/keyrings/
2. Log out and back in via SDDM using your password
3. Observe: keyring prompts for a new password; previously saved secrets are inaccessible
View raw text
**System:** Omarchy 4.0.2-1, kernel 7.1.9-arch1-2 **What happened:** Every time I restart and log in via SDDM with a password (not autologin), my entire GNOME Keyring is effectively wiped — saved app passwords, SSH agent unlock, etc. are all gone and I'm prompted to set a new keyring password as if for the first time. **Root cause (from journal + PAM inspection):** `/usr/share/omarchy/install/login/sddm.sh` intentionally strips `pam_gnome_keyring.so` from the `auth` stage of `/etc/pam.d/sddm`, keeping it only in the `session` stage (`auto_start`). The comment says this is to support a passwordless "Default keyring" design. But when a keyring that isn't the passwordless default already exists on disk (e.g. a normal `login.keyring`), gnome-keyring can no longer obtain the login password at the auth stage to unlock it, and fails: ``` gnome-keyring-daemon: keyring was in an invalid or unrecognized format: /home/<user>/.local/share/keyrings/login.keyring sddm-helper: gkr-pam: couldn't unlock the login keyring. ``` Rather than surfacing an error, it silently creates a brand new empty keyring (prompting for a new password via a GUI dialog) and abandons the old one. Repeated occurrences leave a pile of orphaned duplicate keyring files behind (`Default_Keyring.keyring`, `Default_Keyring_1.keyring`, `login_1.keyring`, etc. — 5+ generations accumulated on my machine). **Expected:** Either the passwordless-default-keyring design should be applied consistently (no legacy password-protected keyring ever gets created/left behind to conflict with it), or the existing keyring should actually be unlocked rather than silently discarded. **Also noticed:** `omarchy debug --no-sudo --print` (referenced in the contributing docs) doesn't exist as a command in 4.0.2-1 — `omarchy commands --all` has no `debug` or `system stats`-style diagnostics dump. **Steps to reproduce:** 1. Fresh/aged Omarchy install where a `login.keyring` (or any non-"Default_keyring"-named keyring) exists in `~/.local/share/keyrings/` 2. Log out and back in via SDDM using your password 3. Observe: keyring prompts for a new password; previously saved secrets are inaccessible
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.