Skip to content

linux/chrome: find Safe Storage in default keyring (not only login) - #116

Open
MabezDev wants to merge 1 commit into
browserutils:masterfrom
MabezDev:fix/linux-chrome-libsecret-default-keyring
Open

linux/chrome: find Safe Storage in default keyring (not only login)#116
MabezDev wants to merge 1 commit into
browserutils:masterfrom
MabezDev:fix/linux-chrome-libsecret-default-keyring

Conversation

@MabezDev

Copy link
Copy Markdown

Summary

On Linux with gnome-keyring, Chrome often stores Chrome Safe Storage in the default keyring (/org/freedesktop/secrets/aliases/default → e.g. Default_5fkeyring), while a separate login collection still exists and does not hold the Chrome secret.

getSecretServicePassword previously used go-keyring's GetLoginCollection(), which hard-codes the login collection whenever that path exists. Search then returned zero items, kooky fell through to KWallet, and callers saw only:

keyring password retrieval failed: kwallet: password not found

even though secret-tool lookup xdg:schema chrome_libsecret_os_crypt_password_v2 works.

Fix

  1. Secret Service: use Service.SearchItems (all collections, same as secret-tool), then fall back to per-collection search in order: default alias → login → remaining collections.
  2. Errors: join primary + fallback keyring errors so a Secret Service miss is not masked by an empty KWallet miss.
  3. Cookie paths: only yield Chromium cookie DB paths that exist (Network/Cookies preferred, else legacy Cookies) so missing layouts do not spam open errors.

Linux v11 cookie crypto was already AES-CBC with the dbVersion ≥ 24 32-byte prefix strip; no change needed there once the keyring password is found (password is used as raw bytes, not base64-decoded).

Verified on

  • Hyprland (non-KDE), gnome-keyring-daemon, Chrome 149, cookie DB at ~/.config/google-chrome/Default/Cookies (meta version 24, v11 ciphertext)
  • After this change, user_session for github.com decrypts successfully via kooky

Test plan

  • go test ./internal/chrome/ ./internal/chrome/find/
  • Integration on a machine with Chrome logged into github.com and secret in default keyring: ReadCookies for user_session returns a non-empty value without GH_SESSION_TOKEN
  • CI on this PR
  • Optional: confirm KDE/KWallet path still works when KDE_SESSION_VERSION is set

go-keyring's GetLoginCollection hard-codes the "login" collection when
that path exists. On common gnome-keyring setups (including non-KDE
desktops like Hyprland) Chrome stores "Chrome Safe Storage" in the
default keyring (aliases/default → Default_5fkeyring) while a separate
login collection still exists and has no Chrome secret.

Search via Service.SearchItems (all collections, same as secret-tool),
then fall back to default alias, login, and remaining collections.
Join primary and fallback keyring errors so a failed Secret Service
lookup is not masked by a subsequent empty KWallet miss.

Also only yield Chromium cookie DB paths that exist (Network/Cookies
or legacy Cookies) so missing layouts do not pollute read errors.
Copilot AI review requested due to automatic review settings July 28, 2026 12:50

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants