v0.81.0 — https:// works out of the box
https:// on a Moshpit name, without a step you have to know about
moshcode dns enable could finish perfectly — bridge up, routing applied, every name resolving — and every https:// URL would still fail. No public certificate authority will ever sign for .eggs, so a name answers with its origin's own self-signed leaf and a stock client refuses it. Correctly: there is nothing there for it to trust.
The fix was real and documented, and it lived in another repository. moshpit-proxy generates one local root and terminates TLS in the one language a browser accepts, which turns "trust this certificate" from something you do per name into something you do once. But it was a separate install, which meant the supported path stopped one step short of working, and the alternative on offer was moshcode dns trust <name> — one name at a time, forever.
install.sh installs it now, and moshcode update re-runs install.sh, so an existing install picks it up on the next update rather than only new ones.
MOSHCODE_NO_PROXY=1 skips it. That is the only opt-out in the installer, and it exists because this is the only part of the install that touches the system's trust store. Nothing here installs DNS routing or starts a resolver: moshcode dns enable remains something a person types deliberately, which is the one thing about this feature that has never been automatic and is not becoming so now.
It covers .moshpit out of the box. For other endings:
MOSHPIT_PROXY_TLDS=moshpit,eggs,hacker,2600A pipeline that could not fail
Worth recording, because the first version of this shipped the bug and a test caught it.
The obvious way to write this step is curl -fsSL "$url" | sh. A pipeline reports the exit status of its last command, and a sh handed empty stdin by a 404 exits 0 — so a download that never arrived reported a successful install. Pointed at a missing URL, it printed ✓ pinned-TLS proxy installed, local root trusted and moved on.
So the installer is downloaded first and run second, and the download is checked. Every failure is reported and none of them are fatal: a machine that cannot reach GitHub for an optional component still wants the CLI it asked for, and being told the proxy is missing is much better than meeting it later as an unexplained TLS error.
Five branches, each verified by hand: it worked, the installer exited non-zero, the URL 404'd, the host was unreachable, and the opt-out was set.