[johnpangalos]

Security fix (M1, medium): wt update fetched a script from the tip of main and executed it under sh.

The problems

src/update.ts originally ran:

const result = await $`curl -fsSL ${INSTALL_URL} | sh`
  .env({ ...(process.env as Record<string, string>), PREFIX: prefix })
  .nothrow();

1. No integrity check on the script itself. install.sh:56-70 carefully verifies the downloaded binary's SHA256 against SHA256SUMS — but the script performing that verification came from raw.githubusercontent.com/johnpangalos/wt/main/install.sh, executed unverified. Anyone who could alter main had code execution on every wt update, and the checksum logic is exactly what they would delete.

2. Partial-download execution. curl | sh hands bytes to the shell as they arrive, so a connection dropped mid-transfer executes a truncated script. set -eu (install.sh:8) does not help — a script cut off before the checksum comparison still runs everything above the cut.

3. Confirm/install mismatch (TOCTOU). cmdUpdate resolved the tag, printed wt vCURRENT → vLATEST, and prompted — then ran the installer without WT_VERSION, so it independently re-resolved releases/latest (install.sh:42-47). The user consented to one version and could receive another.

The fix

Two commits. The first hardened the shell-out (download to a private mkdtemp file, check curl's exit code, run sh <file>, pass WT_VERSION) — that addressed 2 and 3 but left main as a trust dependency. The second removes the shell-out entirely.

src/update.ts now does the update in-process: download → verify → atomic replace, driven by the tag the user confirmed at the prompt.

• Asset resolution (assetName) from process.platform/process.arch, mirroring the platform gate in install.sh:28-33. Only wt-darwin-arm64 is published, so anything else fails with a clear message before any network access rather than guessing at an asset name.
• Download of https://github.com/johnpangalos/wt/releases/download/<tag>/<asset> and .../SHA256SUMS via fetch(), with response.ok checked and the HTTP status surfaced in the error. After this change the only remaining shell-out in the file is gh api in fetchLatestTag().
• Parsing (parseSha256Sums) matches <64 hex><two spaces|space-star><filename> and compares the filename for exact equality. A prefix/suffix match would accept the digest of a different asset whose name merely overlaps. A missing entry is a hard failure.
• Verification with Bun.CryptoHasher("sha256"), compared case-insensitively. On mismatch it aborts with both hashes and installs nothing — the write/rename is physically after this branch, so no path reaches the rename with unverified bytes.
• Staging in the target's own directory — .wt-update-<16 hex> next to the binary, not tmpdir(). rename(2) is only atomic within a filesystem, and ~/.local/bin is very often on a different mount from /tmp (EXDEV). The random suffix keeps the path unpredictable so it cannot be pre-created as a symlink. Written with mode 0o755 plus an explicit chmodSync (writeFileSync's mode is masked by umask).
• Atomic replace via renameSync(tmp, target), where target is realpathSync(process.execPath) — replacing the real file rather than renaming over a symlink and silently detaching the user's wt from what it pointed at. If realpath throws (dangling or unreadable path) it falls back to process.execPath, since updating the path we were invoked as beats aborting; the reason is noted in a comment.
• Cleanup of the staging file in a finally on every failure path (a no-op once the rename has consumed it).
• Errors stay in the wt: ... voice. EACCES/EPERM/EROFS on write or rename report that the install dir is not writable and suggest re-running with permission or reinstalling under a writable prefix — that case previously came out of install.sh and does not regress into a stack trace.

install.sh is not modified — it is still required to bootstrap a machine with no wt on it. cmdUpdate's surrounding behavior is unchanged: fetchLatestTag(), the isNewer gate, promptYes(), the cache write on success, and the returned exit code. The prefix derived from dirname(dirname(process.execPath)) is gone along with its dead imports.

Residual risk (please read)

This removes main as a trust dependency and narrows the trusted surface to the release assets themselves. It does not make updates tamper-proof: a checksum proves transport integrity, not authenticity. Anyone who can publish a release can publish a SHA256SUMS that matches their own binary, and this code would accept it. Closing that requires signing or build attestation (e.g. actions/attest-build-provenance plus verification here). That is a separate decision and explicitly out of scope for this PR — .github/workflows/release-please.yml is untouched.

Tests

tests/update.test.ts (new) — 11 tests, all offline; fixtures are served from an in-process Bun.serve() on localhost and the base URL is injected through an options seam, so no test touches the real network. A dummy target file stands in for the installed binary; bin/wt is never replaced.

• checksum mismatch → returns non-zero, target left byte-for-byte unchanged, no staging file beside it
• valid checksum → target replaced with the new bytes, still mode-executable, no staging file left
• asset absent from SHA256SUMS → refuses, target unchanged
• HTTP error on the binary → refuses; HTTP error on SHA256SUMS → refuses
• SHA256SUMS parsing → correct entry picked among wt-darwin-arm64.sig, xwt-darwin-arm64, wt-darwin-arm, wt-linux-x64; binary-mode ( *) lines and uppercase hex handled; malformed lines and absent assets return null
• unsupported platform → refuses without downloading
• assetName → darwin/x64, linux, and win32 each rejected with their own message

The mismatch test was confirmed non-vacuous: with the actual !== expected branch disabled the suite goes to 10 pass / 1 fail, and only that test fails.

bun run typecheck and bun run test pass (93 tests across 5 files).

Not covered: cmdUpdate's prompt path is still not exercised end-to-end — promptYes() requires /dev/tty, which the CLI test harness cannot supply. The real-target branch (realpathSync(process.execPath)) and the EACCES message are also untested; every test injects an explicit target, and asserting the permission error would need an unwritable directory (root-dependent and flaky in CI).

Not changed (optional follow-up)

README.md still recommends the curl … | sh one-liner for initial install. Left alone deliberately: a first install has no trust anchor on the machine yet, so it is a different risk profile from self-update, and whether to keep the one-liner is a product call.

---

🤖 Generated with Claude Code