Improve password store detection on Linux tiling WMs

[BlueManCZ]

Summary

On Linux tiling WMs (Hyprland, Sway, i3, etc.), Electron's safeStorage API fails to detect the correct password storage backend, even when a keyring like gnome-keyring is installed and running. This causes the "Could not store your password securely" error on startup.

The root cause is that Electron selects the backend based on the XDG_CURRENT_DESKTOP environment variable. When it doesn't match a known desktop environment, it falls back to basic_text and reports isEncryptionAvailable: false — despite org.freedesktop.secrets being available on D-Bus.

This PR adds a startup check that queries D-Bus for an active Secret Service provider. If one is found and the user hasn't explicitly passed --password-store, it sets --password-store=gnome-libsecret so Electron uses the correct backend.

Details

• Only runs on Linux, before the app ready event (where command line switches must be set)
• Uses execFileSync to call dbus-send — no shell spawned, no new dependencies
• Wrapped in try/catch with a 2s timeout — if D-Bus is unavailable, it's a no-op
• Respects any explicit --password-store=... flag the user passes

Related

• Upgrade electron to version 22 #2444 — This was identified during the keytar-to-safeStorage migration, where it was suggested that --password-store=gnome-libsecret should be set automatically for desktop environments that Electron can't recognize. A Sway user on Manjaro confirmed the workaround fixed the issue. This PR implements that suggestion.
• snap: Force usage of libsecret everywhere and remove password manager service plug #2477 — Draft PR that applies the same fix specifically for the snap package by forcing --password-store=gnome-libsecret in the snap wrapper.

Tested on

• Gentoo Linux x86_64 (kernel 6.18.12)
• Hyprland 0.54.3
• gnome-keyring-daemon 48.0

[BlueManCZ]

After digging deeper, I found that Electron has actually addressed this upstream in electron/electron#49054, which closes both electron/electron#39789 and electron/electron#47436.

The fix introduces new async safeStorage methods (encryptStringAsync / decryptStringAsync) that use os_crypt_async, which properly discovers secret service providers without relying on XDG_CURRENT_DESKTOP. However, it's labeled no-backport and semver/major, so it only lands in Electron 42, which is currently in beta and scheduled for stable on May 5, 2026.

So there are two options:

1. Merge this D-Bus detection now and remove it after migration to async safeStorage from Electron 42
2. Wait ~3 weeks for Electron 42 stable and migrate to the async safeStorage API directly

[indent-staging]

It looks like you're not a member of this organization on Indent. To use Indent, visit app.indent.com to get started.

[bengotow]

Hey @BlueManCZ - thanks for submitting this and doing the research to figure out what is going on here. This is great news!

I think the code here looks good, but it might be cleanest to wait for Electron 42 and let the fix happen upstream. Our usage of safeStorage is already inside an async method, so it'll be super easy to move to their new async versions. We're moving from 41.0 to 41.2 in the release this week, so I expect we'll be able to move to Electron 42 as soon as it's out.

[BlueManCZ]

I agree. I'll stay in touch and will update this PR or create new one once I see you upgrade to Electron 42.

[indent-staging]

It looks like you're not a member of this organization on Indent. To use Indent, visit app.indent.com to get started.