v0.4.1 — corporate-network onboarding fixes (pre-alpha)
Pre-releaseA corporate-network onboarding fix release, from two adopter field reports (kept in
docs/adoption/). Both are onboarding-trust bugs on the containerized
default path: one hard-blocked make setup, the other made the Getting-Started
checklist assert something it never actually checked. No interface changes.
Fixed
-
make setupno longer dies on a registry that can't servepnpm. Behind a
corporate allowlist mirror that hasn't onboarded pnpm, the image's default
ui-buildstage failed with a rawnpm error code E404(or 403) and the stack
never came up — the one command the docs tell a new user to run did not work out of
the box.scripts/up.shnow catches a failed build and retries with the UI built on
your host (make ui+WARDYN_UI_STAGE=ui-prebuilt), explaining each step. The
escape hatch was already there; it just required knowing an env var the failure
never named. An explicitWARDYN_UI_STAGEis still honored and disables the
fallback, and the OSS path with a working registry is unchanged — the retry branch
is never entered. Chose retry over probing the registry first: the 404 is on the
tarball path, so a mirror that proxies metadata answers a probe with 200 and the
build dies anyway. -
Staging a corporate CA no longer breaks the image build. The
ui-buildstage
ranupdate-ca-certificates, but itsnode:*-bookworm-slimbase purges the
ca-certificatespackage in its own build, so the binary is absent — meaning any
operator who followedmake doctor's own advice and stageddeploy/images/corp-ca.pem
hit a hardexit 127, every time, before the pnpm step even ran. That stage now
relies onNODE_EXTRA_CA_CERTSalone (npm/pnpm are its only TLS clients, and they
read it).deploy/images/README.md's snippet — which is what produced the bug —
was corrected so it stops reproducing it. -
The Host proxy step tells the truth on the containerized stack. It reported
"No host-side proxy configuration detected" on hosts unambiguously behind a
corporate proxy, in the same session whoseHTTP_PROXYWardyn's own image build had
just consumed.DetectHostProxy()runs in the wardynd process, and in a distroless
container every tier is structurally blind: the env tier sees only the container's
env (compose forwarded the proxy as a build arg only),HOMEis unset so no
shell profile or tool config is reachable, there is nogitbinary, and the OS/PAC
tier dispatches on the process'sGOOS.make setupnow runs the same detector
on the host (newwardyn setup detect-proxy, from a host-native binary the image
cross-compiles) and seeds the result in, recovering the macOSscutil/PAC,
Windows-registry, shell-profile, git and tool-config tiers that are inherently
host-side. It re-runs on everyup, so it cannot go stale across a network change.
Deliberately not done by forwardingHTTP_PROXYinto wardynd's runtime
environment: Go'snet/httphonors those names process-wide, which would silently
reroute wardynd's own OIDC discovery, audit webhooks, GitHub App minting and AWS
credential chain through the corporate proxy — a live-traffic change to fix a
diagnostic. A run's egress is unaffected either way (the sandbox env is built from
scratch and always points at wardyn-proxy). -
An honest empty result when detection genuinely can't look. When wardynd is
containerized and no host-side reading was seeded, the step no longer asserts a
false negative: it says detection ran inside the container, names what it therefore
could not read, and carries a next step. The step's static lede ("Wardyn detected
these host proxy settings…"), which rendered unconditionally above an empty
result, is gone. Same honesty rule the Vault/KVM copy already followed. -
A set-but-empty
HTTP_PROXYno longer counts as a detected proxy.os.LookupEnv
reports ok forexport HTTP_PROXY=, and every consumer downstream tested presence
only — so an empty value rendered a blank-valued "detected" row. Empty and
whitespace-only values are now filtered, in the one place all tiers route through.