Pin Electron password store to gnome-libsecret

[cempack]

Summary

• Ship config/electron-flags.conf so new users pin distro Electron (Element and anything else launched through Arch's electronN wrapper) to gnome-libsecret
• Migrate existing electron-flags.conf and versioned electronN-flags.conf files without overriding an explicit --password-store= choice
• Same Hyprland detection gap already handled for Chromium, and the same approach as the Helium/Signal pins

Test plan

• bash test/shell.d/electron-password-store-migration-test.sh

Made with Cursor

[Copilot]

🟢 Approval recommended

The migration logic matches existing migration runner behavior and is covered by a focused shell test suite, with no correctness issues found in the changes.

Pull request overview

This PR ensures Arch’s distro Electron wrapper (electronN) uses a deterministic keyring backend by pinning the password store to gnome-libsecret, avoiding Hyprland portal/secret-provider detection gaps that can lead to unsupported keyring errors or an unintended fallback store.

Changes:

• Add a default config/electron-flags.conf that pins --password-store=gnome-libsecret for fresh installs.
• Add a migration that seeds ~/.config/electron-flags.conf and updates any ~/.config/electronN-flags.conf files, while preserving any explicit existing --password-store= choice.
• Add a shell test covering commented options, custom options, missing-newline appends, idempotency, and versioned flags behavior.

File summaries

File	Description
test/shell.d/electron-password-store-migration-test.sh	Adds coverage for the migration’s key behaviors (preservation, append rules, idempotency, versioned flags).
migrations/1788631245.sh	Implements the migration to pin Electron password store while respecting explicit user configuration.
config/electron-flags.conf	Ships the default Electron flags pin for new installs.

Review details

• Files reviewed: 3/3 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[sayem314]

@robosayem review this pr

[robosayem]

Approved. Verified the approach end to end.

Wrapper behavior checks out. Arch's electron-launcher reads ${XDG_CONFIG_HOME:-$HOME/.config}/electronN-flags.conf and falls back to electron-flags.conf only when the versioned file is absent (ArchWiki documents this), so pinning both is exactly right: seeding only the fallback would silently do nothing for anyone who already has a versioned file, and this catches that case. Element launches through the distro wrapper, so it is covered.

Convention compliance. The migration follows agents/skills/migrations.md: 0644 mode, no shebang, leading echo, idempotent, and the test invokes it with bash -euo pipefail just like the real runner. The versioned-file loop is correctly scoped with nullglob — without it a no-match glob would create a literal electron[0-9]*-flags.conf.

Improvement over the browser predecessor. 1784508556 used a plain grep -- '--password-store=', which treats a commented-out option as an explicit choice and skips the pin. This PR's ^[[:space:]]*--password-store= ERE fixes that, and there is a test for it.

Two non-blocking notes

1. XDG_CONFIG_HOME: the Arch launcher honors it, but the migration always writes $HOME/.config. A user who relocated their config dir gets the pin written where Electron never reads it. The browser migration shares the limitation, so this is consistency, not a regression.
2. The repo does not appear to reference config/electron-flags.conf anywhere yet — same as config/chromium-flags.conf, so presumably the packaging/skel flow picks it up. Worth a quick confirmation that fresh installs actually ship it, since the test only checks the repo file, not the installed result.

[cempack]

@robosayem review this pr

?