fix: 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 login to fail with Encryption is not available.

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

• Encryption is not available #1981 -- "Encryption is not available" on Arch Linux
• Fail to authenticate in hyprland/wayland #2309 -- "Fail to authenticate in hyprland/wayland"

Tested on

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

[setchy]

Should this fix be upstream in electron itself?

[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.

The migration on Gitify's side should be minimal — literally changing two lines in src/main/handlers/storage.ts, swapping encryptString / decryptString for their async counterparts. The IPC handlers already support async, so no other changes are needed.

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

[setchy]

Thanks for triaging further. Let's wait for v42