feat(desktop): resolve Chromium cookie keys on Linux#7261

🟡 Medium BrowserImport/ChromiumCookies.ts:153

readChromiumCookies reports unsupportedPlatform for every non-ChromiumKeyError thrown by resolveChromiumKeys, so Windows failures such as DPAPI rejection or malformed key output are misclassified on a supported platform instead of reaching BrowserImport as readFailed. Preserve the original error for unexpected failures and only wrap ChromiumKeyError instances.

✅ Resolved in 6a2afea3ed6cc28722026fb50b2134b11a590dad

🟡 Medium BrowserImport/ChromiumKeys.ts:158

readLocalState turns missing, unreadable, and corrupt Local State files into {}, so Windows reports these failures as keychainItemMissing instead of surfacing the metadata read/decoding error. Remove the Effect.orElseSucceed fallback so the caller can report readFailed or an equivalent non-keychain error.

✅ Resolved in 65f945a4fe6761b0856dc6a95989079abc100bb0

BrowserImport/ChromiumKeys.ts:159

readLocalState swallows both the file-read and the JSON/schema decode failure, so a missing, unreadable, or malformed Local State reaches the caller as an empty object and is then reported as ChromiumKeyError({ reason: "keychainItemMissing" }) with no cause and no path context. Consider mapping the failure into the error instead, so the underlying error chain survives and a genuinely absent os_crypt.encrypted_key stays distinguishable from an unreadable file.

No longer relevant as of 65f945a4fe6761b0856dc6a95989079abc100bb0

BrowserImport/ChromiumKeys.ts:140

The PowerShell exit code is never inspected, so a failed Unprotect (or a missing powershell.exe path that still exits) yields empty stdout and this returns a zero-length Buffer. That buffer is truthy, so gcmV10 is populated with an unusable key, every GCM record fails to decrypt in decryptChromiumValue, and the import silently reports zero cookies instead of a typed failure. Consider surfacing it as a ChromiumKeyError (the repo checks exit codes this way in DesktopLinuxUrlHandler.setDefaultHandler):

If you adopt this, the mapper at line 228 should pass an existing ChromiumKeyError through rather than re-wrapping it. Separately, that mapper classifies every spawn/unwrap failure as keychainItemMissing, which renders as "No encryption key in your Keychain — sign in to that browser once, then retry" on Windows; a reason that structurally identifies the unwrap failure (e.g. a readFailed-style literal) would keep the caller-visible copy accurate.

No longer relevant as of 65f945a4fe6761b0856dc6a95989079abc100bb0

DPAPI ignores PowerShell exit status

High Severity

unprotectWithDpapi reads PowerShell stdout and never checks exitCode. Effect does not treat a non-zero exit as failure, so a failed ProtectedData.Unprotect still yields an empty/garbage buffer as gcmV10. Every cookie then decrypts to null and the import returns success with zero cookies instead of a ChromiumKeyError.

^{Reviewed by Cursor Bugbot for commit 6a2afea3ed6cc28722026fb50b2134b11a590dad. Configure here.}

Linux keyring lookup uses wrong attributes

High Severity

Linux v11 key resolution reuses macOS keychainService / keychainAccount with @napi-rs/keyring, which looks up Secret Service by service + username. Chromium stores the OSCrypt secret under schema chrome_libsecret_os_crypt_password_v2 with attribute application (e.g. chrome, msedge). The lookup misses, orElseSucceed drops the error, and only the peanuts v10 key remains—so normal keyring-backed Linux profiles import no v11 cookies.

^{Reviewed by Cursor Bugbot for commit 6a2afea3ed6cc28722026fb50b2134b11a590dad. Configure here.}

🟠 High BrowserImport/ChromiumKeys.ts:232

Linux imports silently omit every v11 cookie when Chromium stores its OSCrypt secret in Secret Service, making the import incomplete. readKeychainSecret uses Keyring.Entry(service, account) with the macOS-style coordinates, but Linux Chromium stores the secret under its custom Secret Service schema (for example, chrome_libsecret_os_crypt_password_v2 with an application attribute); the lookup fails and Effect.orElseSucceed suppresses the error. Use the Linux-specific Secret Service lookup and derive cbcV11 from that result.

✅ Resolved in c188be9758bab40e0a9d93176c917030b2936b4b

Fixed in the updated #7261. Linux v11 key lookup uses Secret Service via secret-tool lookup application with per-browser application attributes, not macOS service/account labels. Missing backend/key can retain partial v10 support; explicit denial or cancellation propagates. Subprocess and whitespace-preservation fixtures pass.

App-bound import looks successful

High Severity

appBoundEncryption is raised only when encrypted_key is missing. Upgraded Chrome still keeps a legacy DPAPI encrypted_key beside app_bound_encrypted_key, so key resolution succeeds, every v20 cookie is skipped, and the import returns success with little or nothing imported and no user-facing app-bound reason.

^{Reviewed by Cursor Bugbot for commit 0ad3689596c830e05d8bdf0a0d16bdf564fb7ab2. Configure here.}

BrowserImport/ChromiumKeys.ts:153

These branches manufacture an Error purely to carry the exit code as text, and label a PowerShell failure keychainItemMissing — the one reason whose user copy tells the user the browser has no key. The exit code is stable, serializable domain context and belongs in a structural attribute (the repo already does this in DesktopLinuxUrlHandlerRegistrationError with exitCode: Schema.optionalKey(Schema.Number) and a message derived from it), and a non-zero exit is readFailed rather than a missing item. Consider adding exitCode to ChromiumKeyError, folding it into message, and dropping the synthetic cause.

No longer relevant as of 1961e3fff8f9c682c259404e9477593109e221ee

BrowserImport/ChromiumKeys.ts:187

readFailed is raised here without the path that failed, so the only path that survives to the log is cookieDatabasePath, attached by the wrapper in ChromiumCookies — a corrupt or unreadable Local State is then reported against the cookie database instead. localStatePath is in scope at this wrapping site; consider adding a path attribute to ChromiumKeyError and setting it here so the failing resource is identifiable.

No longer relevant as of 1961e3fff8f9c682c259404e9477593109e221ee

🟡 Medium BrowserImport/ChromiumCookies.ts:238

readChromiumCookies silently omits every row for which decryptChromiumValue returns null, so Linux v11 and Windows v20 cookies are excluded while the import still reports them as successfully handled (skipped: 0). Track these undecryptable rows in the skipped count (or propagate that count) so partial imports are reported accurately.

✅ Resolved in 8f80c3c6e5aefaab66ab38824050cf361e8f52ae

Wrong Windows failure copy

Medium Severity

DPAPI / PowerShell failures are mapped to keychainItemMissing, whose user copy talks about Keychain and signing into the browser. On Windows that message is misleading for a DPAPI unwrap or Local State problem and steers users toward the wrong fix.

^{Reviewed by Cursor Bugbot for commit ce7944dedd00e2013d48fedf6b869b6daf1e147b. Configure here.}

🟡 Medium BrowserImport/ChromiumCookies.ts:116

A record with a domain hash that does not match domain is returned as plaintext, so the 32-byte hash is decoded into the cookie value and the corrupted or moved cookie is imported instead of rejected. Make stripDomainBinding reject mismatched hashes; the surrounding decryptors will then return null.

✅ Resolved in c188be9758bab40e0a9d93176c917030b2936b4b

Fixed downstack and retained in #7261. Domain binding is required according to meta.version >=24; mismatched bound records are skipped instead of imported as corrupted values. Older long plaintext is preserved. Fixtures use TEXT-affinity version metadata as Chromium does.

Decrypt skips never counted

Medium Severity

Records skipped for missing keys or v20 are dropped with continue and never reach BrowserImportResult.skipped, which only tracks session.cookies.set failures. Callers therefore cannot distinguish an empty database from thousands of intentionally undecryptable cookies, despite the module promising an honestly reported partial result.

^{Reviewed by Cursor Bugbot for commit 2f2f7d0c2f8bf17bdb9872e5975a8ea937fe2ba5. Configure here.}

BrowserImport/ChromiumKeys.ts:272

unprotectWithDpapi fails with ChromiumKeyError | PlatformError — both statically known tags — so this is a known-tag recovery expressed as a negated schema predicate. Effect.catchTags on the single tag being wrapped says the same thing directly, lets the domain error pass through by construction, and makes the module-private isChromiumKeyError (line 86) unnecessary, so it can be deleted along with this change.

No longer relevant as of 7f41045e6ac1f2ef3af6a0f6ef1b824e0a553487

PowerShell may hang on stdin

Medium Severity

ChildProcess.make for DPAPI leaves default stdin: "pipe" and never closes or ignores it. Elsewhere in the desktop app, fire-and-forget spawns set stdin: "ignore". An open stdin pipe can leave powershell.exe blocked, so Windows key unwrap never finishes and cookie import hangs.

^{Reviewed by Cursor Bugbot for commit 7f41045e6ac1f2ef3af6a0f6ef1b824e0a553487. Configure here.}

Accidental profile fixture committed

Low Severity

A dummy cookies.sqlite was committed under apps/desktop/undefined/Profiles/. That undefined segment is a leftover from a run whose home directory was unset, and nothing in the import code or tests reads this path.

^{Reviewed by Cursor Bugbot for commit 3a26a9dc586bfe8e1253a2d25ff619edaa9262db. Configure here.}

🟠 High BrowserImport/ChromiumCookies.ts:237

Linux imports blank out plaintext cookies: when encrypted_value is empty, decryptChromiumValue returns "" even though Chromium stores the real value in the value column. The query does not select that column, so use row.value for empty encrypted blobs (while decrypting non-empty blobs) and include it in CookieRow.

✅ Resolved in c188be9758bab40e0a9d93176c917030b2936b4b

BrowserImport/ChromiumKeys.ts:39

readFailed is never constructed in this module — resolveChromiumKeys/readKeychainSecret only raise keychainItemMissing, needsKeychainApproval, and unsupportedPlatform. ChromiumCookies spreads ChromiumKeyFailure.literals (ChromiumCookies.ts:49-50) specifically to pick it up for its own snapshot/SQL failures, so this failure set advertises a reason ChromiumKeyError cannot carry, and the cookie module's reason set depends on a literal that belongs to it rather than to the key store.

Consider dropping readFailed here and listing it explicitly in ChromiumCookieReadReason alongside browserRunning, so each error's reason set describes only the failures that error can actually represent.

No longer relevant as of c188be9758bab40e0a9d93176c917030b2936b4b

The earlier unused-reason observation was valid for that implementation. The replacement Linux Secret Service implementation now constructs readFailed for real subprocess/backend failures, so removing the reason would be incorrect at the updated head. Its error paths are covered by ChromiumKeys tests.

The | Buffer arm plus the Buffer.isBuffer normalization is a compatibility shim for the pre-ChromiumKeyMaterial signature: the only remaining caller that passes a bare Buffer is ChromiumCookies.test.ts (lines 84, 126, 162, 182, 217-218, 271-272) — production (readChromiumCookies, line 291) always passes ChromiumKeyMaterial. Consider narrowing the parameter to keys: ChromiumKeyMaterial, dropping the keyMaterial normalization, and updating those test call sites to { cbcV10: key }, so the runtime type test disappears and the key shape has one representation.

^{Posted via Macroscope — Effect Service Conventions}

This prefix dispatch is the behavior change this PR is about (a Linux database mixing v10/v11, with unkeyed records skipped rather than failing the import), but no test exercises it: ChromiumKeys.test.ts only asserts which keys get derived, and every ChromiumCookies.test.ts case still uses a v10 fixture with { cbcV10 }. Consider adding a focused case to ChromiumCookies.test.ts — a database holding one v10 and one v11 record read with { cbcV10, cbcV11 } (both decrypt), and the same database read with { cbcV10 } only (the v11 row lands in undecryptable/undecryptableHosts instead of failing the read). The existing encryptV10 helper generalises by parameterising the prefix and key.

^{Posted via Macroscope — Effect Service Conventions}

🟡 Medium BrowserImport/ChromiumKeys.ts:115

A localized keyring denial is classified as readFailed by secretToolFailure, so resolveChromiumKeys silently falls back to v10-only import even after the user denies access. The classification depends on English words in stderr; force secret-tool to use a stable locale or use a locale-independent result to preserve the needsKeychainApproval path.

Fixed in bae4ae9fb414e14abe8a7e1ea6ea8eecc5bcacdc. secret-tool inherits the existing session environment with LC_ALL=C, giving denial classification stable diagnostics without changing the consent flow. The focused test checks that the command preserves inherited environment values and that a denied request remains needsKeychainApproval instead of taking the fallback path. ChromiumKeys tests and desktop typecheck pass.

This new suppression directive has no adjacent explanation, unlike every sibling in this directory (ChromiumCookies.test.ts, Sources.test.ts, FirefoxCookies.test.ts, ChromiumKeys.ts all state why). It also looks unnecessary here: the file imports no node: builtin and uses no Node global, so the diagnostic it disables cannot fire. Consider dropping the line; if it is needed for something I am missing, please add the reason next to it.

^{Posted via Macroscope — Effect Service Conventions}

🟠 High BrowserImport/ChromiumCookies.ts:170

Legacy Linux v10/v11 cookies encrypted with the empty-passphrase fallback are returned as null and skipped, even though Chromium can decrypt them. decryptChromiumValue only attempts the normal cbcV10/cbcV11 key and does not retry with Chromium’s PBKDF2-derived empty-passphrase key used for crbug 1195256 compatibility. Add that fallback key and retry prefixed decryption when the normal key fails.

Fixed in c0f7f052fd. Verified against Chromium’s os_crypt_linux.cc: after a record’s own key fails, Chromium retries with a PBKDF2 key over the empty passphrase (crbug.com/1195256). The Linux key material now carries that key and decryptChromiumValue retries with it on v10/v11 failure — and only when the record’s own key exists and failed, matching Chromium (a missing key still skips). Regression test covers both prefixes plus the no-retry-without-primary-key case.

🟡 Medium BrowserImport/BrowserImport.ts:88

Linux imports now skip legacy Chromium cookie rows as undecryptable, so otherwise readable cookies are omitted. decryptChromiumValue returns null for non-v10/v11 blobs, but Linux Chromium treats blobs without either prefix as legacy cleartext; add that cleartext fallback before counting the cookie as undecryptable.

Fixed in ca1cd02480. Verified against Chromium's os_crypt_linux.cc — same as os_crypt_mac.mm, an unprefixed blob is returned as-is ("old data saved as clear text"). The fallback now applies on Linux too; Windows stays excluded since its app-bound blobs also lack the prefix. Test updated to assert Linux reads it.

Confirmed: Linux now imports unprefixed legacy cleartext blobs, while Windows remains excluded. The original concern is resolved.

🟡 Medium BrowserImport/ChromiumKeys.ts:143

readLinuxSecret can select a non-Chromium Secret Service item, derive the wrong cbcV11, and silently skip every real v11 cookie. The lookup filters only on application; include xdg:schema=chrome_libsecret_os_crypt_password_v2 in the secret-tool predicates.

Confirmed and fixed in 3c1d584a94: the lookup now passes xdg:schema chrome_libsecret_os_crypt_password_v2 alongside application, so only Chromium's own item can match. Test updated.

Confirmed—the schema predicate resolves the concern. Thanks!

🟠 High scripts/build-desktop-artifact.ts:2230

Linux builds requested with arch: "universal" fail while staging stageBrowserSecret, because build-browser-secret.mjs rejects that value even though BuildArch accepts it. Map "universal" to the concrete helper architecture used by the Linux resource monitor (x64), or reject the option before spawning the helper.

Addressed in #9516 (766885b5df): universal maps to x64 before the helper is invoked, mirroring the Linux resource-monitor target resolution; test added.

Helper path dropped at runtime

High Severity

Layer.provide(LinuxBrowserSecret.layer) only makes LinuxBrowserSecretPath available while BrowserImport is constructed, and make never reads it. readLinuxSecret later uses the tag's default undefined, so the bundled helper is never launched and v11 cookies cannot be decrypted.

^{Reviewed by Cursor Bugbot for commit 296acd56139acca917c5c1fa9e193b4775906994. Configure here.}

Windows Helium running state undetected

Medium Severity

Enabling Helium on Windows still uses isSourceRunning's POSIX SingletonLock symlink check. Windows Chromium holds lockfile instead, so a running Helium looks idle. The quit-browser prompt never appears and import can VACUUM INTO a live jar, failing as readFailed or snapshotting mid-write cookies.

^{Reviewed by Cursor Bugbot for commit a771eb69ba4c518dcffaf64da29e3429f8fa1702. Configure here.}

🟠 High scripts/build-desktop-artifact.ts:2224

Linux builds from macOS or Windows hosts succeed without creating stageResourcesDir/browser-secret/t3-browser-secret, so the packaged artifact lacks the configured Linux helper and cannot resolve v11 keys. build-browser-secret.mjs is a no-op on non-Linux hosts; fail these cross-host builds explicitly or provide and stage a target-compatible helper.

Addressed in #9516 (766885b5df): stageBrowserSecret now fails with LinuxBrowserSecretHostError when the host is not Linux, instead of packaging an artifact without the helper; test added.

I can’t find LinuxBrowserSecretHostError or the host-platform guard in the current code; stageBrowserSecret still invokes the helper for every Linux target. The concern remains unresolved in this PR state.

🟠 High browser-secret/main.c:10

Pre-existing Chromium v11 keys stored without a schema-name attribute are reported as missing, so all cookies using those keys are skipped. SECRET_SCHEMA_NONE requires the stored schema name to match, unlike Chromium's lookup; use SECRET_SCHEMA_DONT_MATCH_NAME to retrieve keys created by libgnome-keyring and other compatible backends.

Addressed in #9516 (766885b5df): SECRET_SCHEMA_DONT_MATCH_NAME, so items written without a schema name still match on attributes.

🟠 High src/main.ts:156

Linux cookie imports always report keychainUnavailable when readLinuxSecret runs, even if the bundled helper exists. Layer.provide(LinuxBrowserSecret.layer) hides LinuxBrowserSecretPath after BrowserImport construction, so the later readLinuxSecret effect sees the reference default (undefined); keep the service available with Layer.provideMerge.

Checked and not a bug. BrowserImport.make captures its context with Effect.context at construction and re-provides it to every read (Effect.provide(platformServices) around readChromiumCookies), so LinuxBrowserSecretPath is resolved from the captured context, not the caller's. Verified with a direct test that a Context.Reference supplied via Layer.provide is present in a context captured inside the layer. Leaving as Layer.provide.

The captured platformServices context contains only FileSystem, Path, and ChildProcessSpawner. It does not retain LinuxBrowserSecretPath, so the later explicit Effect.provide(platformServices) masks it. The issue remains; provideMerge is needed.