fix(setup): sync Windows CA certificates to WSL before CLI install#819
fix(setup): sync Windows CA certificates to WSL before CLI install#819jkf87 wants to merge 2 commits into
Conversation
…utdown On Windows, after `wsl --terminate` + `wsl --shutdown`, the localhost proxy process that forwards 127.0.0.1:18789 → WSL2 may take longer than the previous fixed 3-second delay to release the port. When that happened the next step (`preflight-port`) immediately hard-failed with AddressAlreadyInUse and `CanRetry = false`, leaving the user stuck. Changes: - Add `PreflightPortStep.WaitForPortFreeAsync` — polls CanBind every 500 ms up to a configurable ceiling (default 20 s) and returns as soon as the port is free, logging elapsed time when it had to wait. - Replace the fixed `Task.Delay(3000)` in `CleanupStaleDistroStep` with a call to `WaitForPortFreeAsync` so cleanup waits only as long as needed and never longer than necessary. - `PreflightPortStep.ExecuteAsync` also calls `WaitForPortFreeAsync` (10 s ceiling) before the hard check as belt-and-suspenders for the case where cleanup was skipped and something else holds the port briefly. - Expose `CanBind` as `internal static` to enable reuse across the two classes and in new tests. - Add three unit tests covering: immediate return when port is free, successful poll until port is released mid-wait, and full `ExecuteAsync` succeeding after a simulated 300 ms proxy teardown lag. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
On corporate/enterprise networks a TLS-intercepting proxy injects a self-signed certificate that WSL Ubuntu's curl does not trust, causing `install-cli` to fail with exit 60: curl: (60) SSL certificate problem: self-signed certificate in certificate chain Fix: add `SyncWindowsCaCertsStep` between `ValidateWslLockdownStep` and `InstallCliStep` that: 1. Reads the Windows LocalMachine\Root and \CA certificate stores using X509Store and serialises them to PEM format. 2. Writes the bundle directly to the WSL distro filesystem via the `\wsl$\<distro>\usr\local\share\ca-certificates\` UNC share that WSL2 exposes on Windows (no stdin piping required). 3. Runs `update-ca-certificates` as root inside WSL so curl picks up the new trust anchors for the install-script download. The step is intentionally non-fatal: if the Windows cert store cannot be read, the UNC path is unreachable, or update-ca-certificates warns, the step logs and continues so non-proxied setups are not affected. RollbackAsync removes the written bundle file on uninstall. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Codex review: needs real behavior proof before merge. Reviewed June 24, 2026, 10:50 PM ET / 02:50 UTC. Summary Reproducibility: no. high-confidence current-main reproduction was run here. Source inspection shows current main downloads the installer with curl before any CA import, and the PR body provides a setup log with curl exit 60 behind TLS inspection. Review metrics: 3 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Land the enterprise CA repair only after rollback fully removes generated trust-store state, maintainers accept the trust policy, and redacted end-to-end setup logs prove both corporate-proxy and normal-network behavior. Do we have a high-confidence way to reproduce the issue? No high-confidence current-main reproduction was run here. Source inspection shows current main downloads the installer with curl before any CA import, and the PR body provides a setup log with curl exit 60 behind TLS inspection. Is this the best way to solve the issue? No, not as submitted. The CA sync may be the right repair direction, but rollback must refresh the WSL trust store and maintainers still need to accept the default trust policy with real setup proof. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 4e7982bafb86. Label changesLabel changes:
Label justifications:
Evidence reviewedSecurity concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
Problem
On corporate/enterprise networks a TLS-intercepting proxy injects a self-signed certificate into the chain. WSL Ubuntu's curl does not trust Windows-managed certificates by default, so
install-clifails with:Confirmed from setup log (
setup-engine-20260625-023033.jsonl):This affects any Windows machine on a network with TLS inspection (common in enterprise environments).
Fix
Add
SyncWindowsCaCertsStepbetweenValidateWslLockdownStepandInstallCliStep:LocalMachine\Root+LocalMachine\CAcertificate stores viaX509Storeand serialise to PEM\wsl$\<distro>\usr\local\share\ca-certificates\windows-ca-bundle.crt(no stdin piping needed)update-ca-certificatesas root in WSL so curl picks up the corporate CA trust anchorsThe step is non-fatal: if the Windows cert store is unreadable, the UNC path is unreachable, or
update-ca-certificateswarns, the step logs and continues — so non-proxied setups are completely unaffected.RollbackAsyncremoves the written bundle on uninstall.Test plan
install-clishould now succeedwindows-ca-bundle.crtis removed from WSL🤖 Generated with Claude Code