Secret Service & keyrings

Noctalia stores durable secrets through the desktop Secret Service. Two subsystems depend on it:

• The encrypted storage master key, from which the clipboard-history and calendar-event-cache keys are derived. See Encrypted storage master key.
• Calendar credentials: CalDAV passwords and Google refresh tokens. See Calendar credential storage.

A Secret Service provider must run in your login session: GNOME Keyring, KWallet, or KeePassXC. libsecret is only the client library; installing it alone does not start or configure a provider, and Noctalia never ships or manages one.

Collections and the default alias

Noctalia follows the Secret Service standard and writes to the provider’s default collection. default is an alias the provider or user selects; Noctalia never forces a provider-specific collection and never changes that system-wide alias.

For secrets to be readable after login, the collection the default alias points to must be unlocked, either automatically at login or on demand by the provider. Noctalia cannot supply a keyring password after login, and it never moves secrets between keyrings.

GNOME Keyring: the “Login” keyring and multiple keyrings

With GNOME Keyring, PAM unlocks the Login keyring from your login password. But Login is not guaranteed to be the default when more than one keyring exists. If your secrets live in a keyring that nothing unlocks at login, Noctalia’s startup lookup finds them locked, even when the collection reported by the default alias is a different, unlocked (and possibly empty) keyring.

The symptom: clipboard history, the calendar cache, or calendar credentials are unavailable after every reboot, and become available only after a second login unlocks the other keyring.

To fix it, make the keyring that holds your secrets the one PAM unlocks:

1. Open Passwords and Keys (Seahorse).
2. Set the Login keyring as the default.
3. Reconnect any affected Google account once so its refresh token is rewritten into the now-default keyring, and re-save any other secrets that were in the wrong keyring.
4. Reboot and confirm the secrets are available immediately.

Alternatively, configure whichever keyring is currently the default to unlock automatically at login. Consolidating to a single keyring avoids the problem entirely.

Automatic recovery

When a provider is missing or its collection is locked at startup, Noctalia keeps working for the session but does not read from or write to encrypted storage. It reopens on its own, without a manual retry, when either:

• a provider starts after Noctalia and claims org.freedesktop.secrets (a common race when the keyring launches from the same session startup script), or
• a provider that was already present unlocks its default collection later in the session (for example once PAM or a keyring prompt opens it).

Recovery only succeeds when the wanted secret is in the collection that unlocks; if it lives in a different keyring, use the fix above. You can also force a retry from Settings (for example Settings → Shell → Clipboard → Retry, or the calendar Retry actions).

Avoiding Secret Service entirely

Both subsystems support a keyring-free, file-based source for headless or declaratively provisioned setups (agenix, sops-nix, systemd credentials):

• Storage master key: [storage].key_source = "file".
• CalDAV passwords: credential_source = "file". Google refresh tokens are writable credentials and always require Secret Service.

Security note

Secret Service protects durable secrets in copied home directories and offline storage while the keyring is locked. It is not a security boundary against arbitrary programs already running as your user once the keyring is unlocked.