Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

Relationships

#2314 Platform certificate load failure surfaces as an uncaught error on network commands

Opened by hammz · 9/21/2026

Split out of swamp-club#2293, which is scoped to the crash-on-import only.

What 2293 fixes, and what it leaves

2293 removes two module-level Deno HTTP clients (src/cli/remote_run.ts:765 and src/worker/connect.ts:52) that were constructed at import time. Because src/cli/mod.ts is on that import path, a host whose platform certificate store cannot be read died before argument parsing — every command, including 'swamp help' and the built-in issue reporter. After that fix, local commands run normally.

What remains: on the same host, any command that actually reaches the network still fails, because the platform certificate store is read when the connection is established. The failure moves from startup to the command that needed it, which is the correct place for it, but the presentation is still an uncaught runtime error rather than something a user can act on.

Why this is its own issue

Different code path, different acceptance criteria. diagnoseTlsMessage in src/cli/remote_run.ts pattern-matches the text of a WebSocket close message; this error is thrown synchronously while the HTTP client is being constructed, so it never reaches that function. Folding it into 2293 would mean shipping an error-presentation change under a crash fix and widening a deliberately narrow diff.

What good looks like

A command that cannot build a TLS client because the platform store is unreadable should fail with an actionable UserError that names the condition and the override, rather than an uncaught error with an internal stack trace. The override that is known to work for the original reporter is setting the Deno TLS CA store environment variable to mozilla.

One thing not to do

Do not silently fall back to the bundled mozilla root store when the platform store fails. That changes the set of trusted roots without the operator knowing, and an organisation relying on a corporate root installed in the system keychain would quietly lose it while connections appear to keep working. Diagnose and instruct; let the operator opt in.

Reproduction

Not reproducible in-house. The original report is from macOS 26.6.2 build 25G83 on arm64, swamp 20260918.211634.0-sha.bcaa9695, failing in SecTrustSettingsCopyCertificates. A second macOS 26.6.2 arm64 machine on the same build does not reproduce it, so the trigger is the contents of the reporter's keychain. Confirming a fix will need help from the reporter of 2293.

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

9/21/2026, 3:21:51 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.