Background
Our Linux master-key retrieval only talks to freedesktop Secret Service via go-dbus-keyring. On systems where Secret Service isn't on the session bus — typically KDE installs without a ksecretservice bridge (see #161) — we fall back to the hardcoded peanuts key and silently lose any v11 data.
Chromium's os_crypt picks from several backends based on XDG_CURRENT_DESKTOP or --password-store: GNOME_LIBSECRET, KWALLET4/5/6, BASIC_TEXT. We should match that coverage.
What to do
- Add native
KWallet5 / KWallet6 retrievers (direct org.kde.kwalletd5 / org.kde.kwalletd6 D-Bus calls; godbus/dbus/v5 is already vendored, no new dependency).
- Build a desktop-env-aware chain so KDE users get
KWallet → Secret Service → peanuts instead of Secret Service → peanuts.
- Optional: expose a
--password-store flag so users can override the chain.
Related
Background
Our Linux master-key retrieval only talks to freedesktop Secret Service via
go-dbus-keyring. On systems where Secret Service isn't on the session bus — typically KDE installs without aksecretservicebridge (see #161) — we fall back to the hardcodedpeanutskey and silently lose anyv11data.Chromium's
os_cryptpicks from several backends based onXDG_CURRENT_DESKTOPor--password-store:GNOME_LIBSECRET,KWALLET4/5/6,BASIC_TEXT. We should match that coverage.What to do
KWallet5/KWallet6retrievers (directorg.kde.kwalletd5/org.kde.kwalletd6D-Bus calls;godbus/dbus/v5is already vendored, no new dependency).KWallet → Secret Service → peanutsinstead ofSecret Service → peanuts.--password-storeflag so users can override the chain.Related
v11prefix recognition, already on main