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:
-
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:
-
vp's HTTP client doesn't speak the sfw integration surface. Survey of voidzero-dev/vp (commit at time of PR feat: add sfw input to wrap vp install with Socket Firewall Free #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):
- 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.
- 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).
- Inject extra CAs from SSL_CERT_FILE (industry-standard env var also set by sfw) via ClientBuilder::add_root_certificate(reqwest::Certificate::from_pem(…)).
- 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
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:
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:
vp's HTTP client doesn't speak the sfw integration surface. Survey of voidzero-dev/vp (commit at time of PR feat: add sfw input to wrap vp install with Socket Firewall Free #72):
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:
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):
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:
Related