## What happened

On a stock Omarchy install with autologin, an unlock dialog started appearing on every boot:

> **Authentication required** — An application wants access to the keyring "Default Keyring", but
> it is locked.

Nothing in the dialog identifies the cause, and it began days after the change that triggered it.
The root cause is that Omarchy's passwordless cleartext default keyring cannot survive an
application storing a **multi-line secret** — and once it is corrupted, autologin guarantees the
replacement keyring can never be unlocked automatically.

## Expected

Either the passwordless keyring keeps working regardless of what a Secret Service client stores,
or the breakage is surfaced as itself rather than as a recurring password prompt for a keyring the
user never knowingly created.

## Mechanism

1. `install/user/default-keyring.sh` writes `~/.local/share/keyrings/Default_keyring.keyring` in
   gnome-keyring's **cleartext** format (no password), and `install/login/sddm.sh` strips the
   `pam_gnome_keyring` auth lines from `/etc/pam.d/sddm`. This is deliberate and necessary:
   autologin means PAM never receives a password, so a password-protected keyring could never be
   unlocked (`gkr-pam: no password is available for user` on every boot).
2. The cleartext format is line-based INI, with each secret written as a single `secret=` line. Any
   application that stores a value containing a newline therefore writes a file gnome-keyring can
   no longer parse. In my case Ente Auth (`ente-auth-bin`, via `flutter_secure_storage_linux`)
   stored a 194-byte pretty-printed JSON blob containing 4 raw newlines.
3. The write reports success and works for the rest of that session, because the daemon serves it
   from memory. On the next boot:

   ```
   gnome-keyring-daemon[1060]: keyring was in an invalid or unrecognized format: \
       /home/<user>/.local/share/keyrings/Default_keyring.keyring
   ```

4. The daemon rejects the **entire file**, so unrelated secrets go with it — here Chromium's
   `Chromium Safe Storage` key, which Omarchy itself points at libsecret (see #10346). With no
   loadable default keyring, the next client to ask for a secret triggers gnome-keyring's
   create-a-keyring prompt, and the keyring that gets created is **password-protected**
   (`Default_Keyring.keyring`, with `~/.local/share/keyrings/default` repointed to it).
5. From then on, every boot: autologin gives gkr-pam nothing, the keyring stays locked, and the
   first autostarted Secret Service client raises the dialog. On my machine that is the Remmina
   applet, four seconds into the session.

## Steps to reproduce

1. Stock Omarchy install with autologin enabled (the default).
2. Install any application that stores a multi-line secret via libsecret — e.g.
   `ente-auth-bin`, or any Flutter app using `flutter_secure_storage` — then launch it and sign in.
3. `journalctl -b | grep -i 'unrecognized format'` — the default keyring is already unparseable.
4. Reboot. Accept the keyring-creation prompt (or let an app trigger it).
5. Reboot again → the "Default Keyring is locked" dialog now appears on every boot.

## Evidence

```
# every boot, twice
gnome-keyring-daemon[1060]: keyring was in an invalid or unrecognized format: \
    /home/<user>/.local/share/keyrings/Default_keyring.keyring

# every boot, inherent to autologin
sddm-helper[1100]: gkr-pam: no password is available for user
sddm-helper[1100]: gkr-pam: couldn't unlock the login keyring.

# the corrupting record, as written into the cleartext keyring (values redacted)
[3]
item-type=0
display-name=io.ente.auth/FlutterSecureStorage
secret={
  "auth_secret_key": "<REDACTED>",
  "key": "<REDACTED>",
  "secret_key": "<REDACTED>",
}
mtime=1788365819
ctime=1788365819
```

## System details

- Omarchy 4.0.3-1, Arch Linux, kernel 7.2.3-arch1-3
- gnome-keyring 1:50.0-1, libsecret 0.21.7-1, sddm 0.21.0-7
- `/etc/sddm.conf.d/autologin.conf` with `User=`/`Session=omarchy.desktop`
- LUKS full-disk encryption, passphrase at boot, no TPM enrollment
- Trigger package: `ente-auth-bin` 4.4.24-1

(`omarchy debug --no-sudo --print` is referenced in the contributing docs but there is no `debug`
route in 4.0.3 — `omarchy commands --all` has no match — so the above is assembled by hand.)

## Suggested directions

- **Don't let it fail silently.** Detect an unparseable keyring at login and surface it, rather
  than letting gnome-keyring quietly create a password-protected replacement that autologin can
  never open. The user-visible symptom is currently indistinguishable from an unrelated
  misconfiguration.
- **Or move off the cleartext format.** Provision a password-protected keyring and unlock it at
  session start from a `0600` file in the user's home — the binary format stores secrets as opaque
  byte buffers, so arbitrary bytes are safe. On a LUKS install this is the same security boundary
  the cleartext keyring already relies on. That is what I did locally: a `Type=oneshot` user unit
  ordered `Before=xdg-desktop-autostart.target` that calls
  `org.gnome.keyring.InternalUnsupportedGuiltRiddenInterface.UnlockWithMasterPassword` on the
  collection returned by `ReadAlias("default")`. It runs about three seconds before the first
  autostarted client asks for a secret.
- **At minimum, document the constraint**, since the failure mode is silent, delayed, and
  presents as an unexplained password prompt.

The app-side fix is being tracked upstream at
juliansteenbakker/flutter_secure_storage#951 (base64-encode before storing). But storing a
newline-containing secret is legal per the Secret Service API and round-trips fine in a
password-protected keyring, so any Secret Service client can reproduce this — it isn't specific to
Ente Auth or to Flutter.

## Possibly related

- #9235 — same end state (secrets orphaned, keyring recreated), different mechanism: two daemons
  racing on the file. Worth checking whether some reports there are actually this bug.
- #10243 / #10396 — `pam_gnome_keyring` stripped from `sddm` but not `sddm-autologin`
- #10127 — closed: keyring recreated on password-based SDDM login
- #4004 — closed: "Keyring 'Default' asked to be created at every start up"
- #10346 — pins Electron's password store to `gnome-libsecret`, which widens the set of apps
  writing into this keyring
- #10984 — pins gcr-prompter's workspace, i.e. treats the symptom's placement