Track: enable `sfw` on macOS/Windows once vp + sfw upstream TLS issues are resolved

Background

PR #72 added an sfw input that wraps vp install with Socket Firewall Free. On macOS / Windows runners the wrapped install failed with tlsv1 alert unknown ca, so the action currently falls back to plain vp install with a warning on non-Linux.

This issue tracks the work needed (on both sides) to re-enable sfw everywhere.

Root cause

The failing call is vp's preflight to https://registry.npmjs.org/pnpm/latest, which sfw MITM-proxies. The handshake fails before sfw can inspect the install because two independent problems stack:

1. sfw issues a CA certificate with a present-but-empty Extended Key Usage extension. OpenSSL is lenient and accepts it; rustls (which vp uses) and Go crypto/x509 reject it as UnknownIssuer. Tracked upstream:

   • SocketDev/sfw-free#30
   • SocketDev/sfw-free#43

2. vp's HTTP client doesn't speak the sfw integration surface. Survey of voidzero-dev/vp (commit at time of PR #72):

   • reqwest 0.13 with default-features = false, no auto-proxy, no auto-CA
   • macOS/Linux uses rustls with the baked Mozilla bundle — rustls-native-certs is not in use, so installing sfw's CA into the OS keychain does nothing
   • No SSL_CERT_FILE / NODE_EXTRA_CA_CERTS / add_root_certificate handling
   • No HTTPS_PROXY / HTTP_PROXY / NO_PROXY honoring (bare reqwest::get(url) calls; no Client::builder().proxy(…))
   • Bootstrap site: crates/vite_install/src/package_manager.rs:471-481 (HttpClient::new().get_json(…))

Ubuntu happens to pass today because GitHub's ubuntu-latest runner has pnpm preinstalled, so vp skips the bootstrap fetch entirely and never touches sfw's proxy.

For reference, npm / pnpm work with sfw because sfw injects a richer env into the child process — confirmed via strings on the sfw v1.10.0 binary:

// from inside sfw's getSubProcessEnv()
HTTP_PROXY, HTTPS_PROXY, http_proxy, https_proxy,
SSL_CERT_FILE, SSL_CERT_DIR, NODE_EXTRA_CA_CERTS,
YARN_HTTP_PROXY, YARN_HTTPS_PROXY, YARN_HTTPS_CA_FILE_PATH,
PIP_CERT, CARGO_HTTP_CAINFO, CARGO_HTTP_PROXY,
GIT_SSL_CAINFO, GIT_PROXY_SSL_CAINFO

Node-based clients pick up NODE_EXTRA_CA_CERTS + HTTPS_PROXY automatically. vp does not.

Work to unblock macOS / Windows

Track A — upstream sfw

Wait for SocketDev to ship a release with the EKU fix from #30 / #43. Pin sfw to a known-good version once available.

Track B — vp (separate PR against voidzero-dev/vp)

Minimum-viable change for sfw-compatibility (~80 LOC):

1. Centralize HTTP into a single configurable reqwest::Client (replace per-call reqwest::get(url) with a shared client). Touches crates/vite_install/src/request.rs.
2. Honor HTTPS_PROXY / HTTP_PROXY / NO_PROXY via Client::builder().proxy(reqwest::Proxy::https_from_env()). Enable reqwest's http-proxy feature (currently disabled because of default-features = false).
3. Inject extra CAs from SSL_CERT_FILE (industry-standard env var also set by sfw) via ClientBuilder::add_root_certificate(reqwest::Certificate::from_pem(…)).
4. Add VP_INSECURE_TLS=1 opt-in as a diagnostic escape hatch (loud warning at startup; never recommended for production).

Phase-2 (separate PR, behind a flag, then default-on):
5. Switch macOS/Linux from baked Mozilla bundle to rustls-native-certs so OS-installed CAs (sfw, corporate MDM, etc.) work without env vars.

When both tracks land

In setup-vp:

• Remove isSfwSupported() Linux gate in src/index.ts
• Drop the non-Linux fallback warning + revert effectiveSfw plumbing
• Restore the assertions in test-sfw (sfw --version should resolve on all three OSes)
• Remove the [!IMPORTANT] Linux-only callout from the README

Related

• PR: voidzero-dev/setup-vp#72
• Upstream sfw: SocketDev/sfw-free#30, SocketDev/sfw-free#43