Skip to content

Discussion: drop new Firefox notice, rely on existing notice + refetch-on-focus - #3488

Closed
ivan-ottinger wants to merge 1 commit into
rsm-2943-linux-show-in-app-cert-trust-notice-with-browser-specificfrom
rsm-2943-firefox-trust-alternative
Closed

Discussion: drop new Firefox notice, rely on existing notice + refetch-on-focus#3488
ivan-ottinger wants to merge 1 commit into
rsm-2943-linux-show-in-app-cert-trust-notice-with-browser-specificfrom
rsm-2943-firefox-trust-alternative

Conversation

@ivan-ottinger

@ivan-ottinger ivan-ottinger commented May 14, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Related issues

Context

This is a draft companion to #3472 to make the alternative I sketched in this review thread easier to look at as code. It's not a merge candidate — it targets #3472's branch so the diff shows exactly what I'd remove and what I'd keep relative to that PR. Close it once we agree on a direction.

What this PR proposes

Keep the substantive fix from #3472 (auto-importing the Studio CA into existing Firefox profile NSS DBs, and including Firefox profiles in the trust check). Drop the new in-app Firefox notice and the IPC/detection plumbing that exists only to feed it.

Both PRs benefit from refetchOnFocus: true (already set on certificateTrustApi since the monorepo restructure) + setupListeners(store.dispatch) (already wired in stores/index.ts). When the user opens Firefox for the first time after clicking Trust, the next focus event re-runs isRootCATrusted(), the freshly-created profile DB no longer satisfies areAllFirefoxProfilesTrustedLinux, and trust flips back to false. In #3472 both the existing notice and the new Firefox-specific notice reappear; in this alternative only the existing notice does. One more Trust click imports into the new profile with no sudo prompt (system bundle install is skipped when the cert is already in /etc/ssl/certs).

Proposed Changes

Removed (only exists to feed the new notice):

  • apps/studio/src/lib/detect-linux-browsers.ts + its test
  • getLinuxBrowserCertSupportStatus IPC handler in ipc-handlers.ts
  • Preload binding in preload.ts
  • getLinuxBrowserCertSupportStatus RTK Query endpoint + hook in certificate-trust-api.ts
  • docsSslLinuxFirefox in get-localized-link.ts (rely on the existing docsSslInStudio page with a Linux/Firefox subsection)
  • The Firefox notice + isLinux and useGetLinuxBrowserCertSupportStatusQuery imports in content-tab-settings.tsx

Kept (the substantive fix from #3472):

  • importCAIntoFirefoxProfilesLinux, areAllFirefoxProfilesTrustedLinux, getLinuxFirefoxProfileDbDirs in tools/common/lib/linux-trust-store.ts
  • The composition in isRootCATrusted() and the import call in trustRootCA()
  • All 12 trust-store tests

Net diff vs. #3472: −128 lines, +4 lines.

Why I think this is worth considering

  • Less code to maintain. −128 / +4 line net delta, with the Firefox auto-import behavior preserved unchanged.
  • Avoids misleading copy in the "no profile yet" state. Linux: auto-trust Firefox profiles and surface in-app cert notice #3472's Firefox-specific notice fires whenever firefoxDetected && !isCertificateTrusted, including when Firefox is installed but no profile exists yet. In that state the copy says "import it manually to avoid the security warning" even though there's nothing to import into — and when the user does open Firefox later, the auto-import will handle it for them on the next Trust click. The alternative defers to the existing notice, which makes no Firefox-specific promise it can't keep.
  • One notice instead of two stacked notices. When Firefox is detected and the cert is untrusted, Linux: auto-trust Firefox profiles and surface in-app cert notice #3472 renders two notice paragraphs in the same row. The alternative renders one, with the Firefox specifics living in the existing SSL docs page under a Linux subsection.

Testing Instructions

The following were verified end-to-end on a Linux VM with Snap Firefox installed:

  • Trust click — system bundle (pkexec) + Chromium NSS + existing Snap Firefox profile all imported.
  • Trust state regresses (cert removed from Firefox profile) → existing notice + Trust link reappear when Studio regains focus.
  • Subsequent Trust click runs without sudo prompt; only NSS imports execute.
  • Firefox installed but no profile yet → trust check stays vacuously true, notice stays hidden.
  • Firefox opened for the first time after Trust click → existing notice reappears on focus; one more Trust click silently imports the cert into the freshly-created profile.
  • All unit tests pass (npx vitest run tools/common/lib/tests/linux-trust-store.test.ts — 12/12; full studio suite 82 files / 639 tests).

Findings outside this PR's scope

During testing we hit a pre-existing bug in the trust check that's independent of which notice approach lands: certutil -L -d sql:<db> -n "WordPress Studio CA" fails to verify trust when the cert exists in the NSS DB under a different nickname — e.g., the <CN> - <Org> pattern Firefox uses when a user manually imports via the certificate manager. NSS dedupes by certificate content on -A, keeping the existing nickname, so the cert ends up trusted but Studio's UI continues to nag. Pattern was introduced in #3268 (Chromium NSS) and inherited by #3472 (Firefox profiles, where the collision is more likely). To be filed and fixed separately.

Pre-merge Checklist

  • N/A — discussion draft, not for merge.
@ivan-ottinger @claude
Drop in-app Firefox notice and detection plumbing
c705bbf 
Alternative to the new Firefox notice: rely on the existing untrusted-cert
notice + refetchOnFocus (already enabled on certificateTrustApi) to surface
the case where Firefox is opened after the initial Trust click and a new
profile DB appears without the Studio CA.

- Remove the Firefox notice in content-tab-settings
- Remove isFirefoxInstalledOnLinux + detect-linux-browsers tests
- Remove getLinuxBrowserCertSupportStatus IPC handler + preload binding
- Remove the second RTK Query endpoint + hook
- Remove docsSslLinuxFirefox (rely on docsSslInStudio)
- Keep the substantive fix: importCAIntoFirefoxProfilesLinux,
  areAllFirefoxProfilesTrustedLinux, getLinuxFirefoxProfileDbDirs, and
  the composition in isRootCATrusted / trustRootCA

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@ivan-ottinger ivan-ottinger mentioned this pull request May 14, 2026
Merged
1 task
@ivan-ottinger

ivan-ottinger commented May 15, 2026

Copy link
Copy Markdown
Contributor Author

Since the proposed changes have been committed to #3472, I am closing this PR. ✅
gavande1 added a commit that referenced this pull request May 18, 2026
@gavande1 @ivan-ottinger @claude
Linux: auto-trust Firefox profiles and surface in-app cert notice (#3472
0197303 
)

## Related issues

- Fixes [RSM-2943](https://linear.app/a8c/issue/RSM-2943) — Linux:
auto-trust the Studio CA in Firefox profiles
- Fixes [RSM-2944](https://linear.app/a8c/issue/RSM-2944) — Linux:
auto-install root CA into Firefox profiles

## How AI was used in this PR

Implementation drafted with Claude Code. Tests, types, and the flow
described in the testing instructions below were verified manually
inside the Linux VM. @ivan-ottinger also drafted #3488 to demonstrate a
simpler alternative that drops the in-app Firefox-specific notice and
relies on `refetchOnFocus` for the trust-after-first-launch case; that
commit has been folded into this PR.

## Proposed Changes

- Extend `trustRootCA()` on Linux to also import the Studio CA into
every existing Firefox profile NSS DB (`cert9.db`) across apt
(`~/.mozilla/firefox/*.default*`), Snap
(`~/snap/firefox/common/.mozilla/firefox/*.default*`), and Flatpak
(`~/.var/app/org.mozilla.firefox/.mozilla/firefox/*.default*`) install
roots.
- Extend `isRootCATrusted()` on Linux to also verify each existing
Firefox profile contains the cert, so the existing **Trust Certificate**
notice reappears if a profile drifts. Profiles that don't exist yet are
vacuously trusted (Firefox creates `cert9.db` on first launch — nothing
to check or import into until then).
- New `tools/common/lib/linux-trust-store.ts` helpers:
`getLinuxFirefoxProfileDbDirs`, `areAllFirefoxProfilesTrustedLinux`,
`importCAIntoFirefoxProfilesLinux`. They mirror the existing
`getLinuxNssDbCandidates` / `isCAImportedInUserNssDbsLinux` /
`importCAIntoUserNssDbsLinux` pattern.
- The "Firefox installed but never launched" gap is handled by the
existing `refetchOnFocus: true` on `certificateTrustApi` +
`setupListeners(store.dispatch)` in `stores/index.ts`. When the user
launches Firefox for the first time and returns focus to Studio, the
trust check re-runs, finds an untrusted new profile DB, and the existing
notice + **Trust Certificate** button reappear. One more click silently
imports into the new profile (no sudo prompt — the system bundle install
short-circuits when the cert is already in `/etc/ssl/certs`).

## Testing Instructions

Run inside the Linux VM (`ssh parallels@10.211.55.3`, project at
`/home/parallels/Desktop/studio-linux`).

**Auto-import into existing Firefox profile**

1. Launch Firefox at least once so a `.default*` profile with `cert9.db`
exists.
2. Make sure the Studio CA is currently untrusted (see _Reset_ below).
3. Start Studio, open a site, enable HTTPS. The HTTPS row shows
_Disabled / Enabled_ with a **Trust Certificate** button and the
untrusted-cert notice.
4. Click **Trust Certificate**, complete the polkit prompt. Button and
notice disappear.
5. Verify the cert landed in Firefox: `certutil -d
sql:$HOME/.mozilla/firefox/<id>.default-release -L -n 'WordPress Studio
CA'` should succeed. Repeat for the snap / flatpak profile roots if you
have those installations.
6. Open the site in Firefox — no security warning.

**Firefox installed but never launched (trust-then-launch flow)**

1. Reset trust (see _Reset_ below) and remove any Firefox profile dirs:
`rm -rf ~/.mozilla/firefox ~/snap/firefox/common/.mozilla/firefox
~/.var/app/org.mozilla.firefox/.mozilla/firefox`.
2. Start Studio, open a site, enable HTTPS. Click **Trust Certificate**.
3. System bundle + Chromium NSS import happen; Firefox import is a no-op
(no profile yet). Button and notice hide.
4. Launch Firefox for the first time, then return focus to Studio.
5. The untrusted-cert notice + **Trust Certificate** button reappear
(refetch-on-focus picks up the freshly-created profile DB).
6. Click **Trust Certificate** again — should run without a polkit
prompt (system bundle is already trusted; only the NSS imports execute).
7. Reload the site in Firefox — no security warning.

**Trust-state regression**

1. With cert trusted, remove just the Firefox profile copy:
`certutil -d sql:$HOME/.mozilla/firefox/<id>.default-release -D -n
'WordPress Studio CA'`
2. Return focus to Studio → notice + Trust button should reappear on
refetch.



https://github.com/user-attachments/assets/0d4b53f0-e96e-41aa-9518-53741c75dd0f

> Note: the recording above was made before #3488's changes were folded
in; it shows the older flow that included a second Firefox-specific
notice. The current behavior matches the steps above (one notice, not
two).


**No regressions on macOS / Windows**

- On both, the Trust Certificate flow behaves exactly as before; nothing
Linux-specific is triggered.

**Reset trusted certificate (for re-testing)**

```bash
sudo rm -f /usr/local/share/ca-certificates/studio-ca.crt && sudo update-ca-certificates --fresh
certutil -d sql:$HOME/.pki/nssdb -D -n 'WordPress Studio CA' || true
certutil -d sql:$HOME/snap/chromium/current/.pki/nssdb -D -n 'WordPress Studio CA' 2>/dev/null || true
for p in $HOME/.mozilla/firefox/*.default* $HOME/snap/firefox/common/.mozilla/firefox/*.default* $HOME/.var/app/org.mozilla.firefox/.mozilla/firefox/*.default*; do
  [ -d "$p" ] && certutil -d sql:"$p" -D -n 'WordPress Studio CA' 2>/dev/null || true
done
```

**Tests**

```bash
npm test -- tools/common/lib/tests/linux-trust-store.test.ts apps/studio/src/components/tests/content-tab-settings.test.tsx
```

## Pre-merge Checklist

- [ ] Have you checked for TypeScript, React or other console errors?

---------

Co-authored-by: Ivan Ottinger <25105483+ivan-ottinger@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant

@ivan-ottinger