setup-host.sh: pipes Rust install script directly to sh — no checksum, no version pin

[jelloee]

scripts/setup-host.sh:

say "Installing Rust (if missing)..."
if ! command -v cargo >/dev/null; then
    curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
    source "$HOME/.cargo/env"
fi

This is the upstream-recommended Rust install path, so it's not unusual. But for a project that takes operator security seriously elsewhere (the systemd unit is hardened, the audit log story is in place), the curl-pipe-sh pattern stands out:

1. No checksum. A compromise of sh.rustup.rs (TLS termination at Cloudflare, etc.) would inject arbitrary shell into every developer's machine running this script.
2. No version pin. A new Rust release that breaks the project's rust-toolchain.toml would silently land in the host environment.

Both are mitigated by the fact that rust-toolchain.toml exists and cargo honors it — so the project builds with the right toolchain anyway. The installed cargo itself doesn't matter much, since rustup will fetch the pinned toolchain on first cargo build.

Still, two pragmatic improvements:

1. Mention in the comment that the project pin comes from rust-toolchain.toml, so installing the latest rustup is intentional and safe.
2. If a future operator-paranoid mode is wanted, switch to the rustup-init binary download + sha256 verify pattern.

Severity: Low / supply-chain hygiene.

[WaylandYang]

Thanks for the careful read, @jelloee — exactly the kind of report that's worth replying to with reasoning rather than just closing as wontfix.

I went with your option 1 (comment explaining the rust-toolchain.toml bound) in #237, now merged. The TL;DR I committed alongside the install line:

The rustup binary version that lands here does NOT determine what compiler forkd actually builds with — rust-toolchain.toml at the repo root pins the channel, and rustup fetches that toolchain on first `cargo build`. So a supply-chain compromise of `sh.rustup.rs` would still be bounded by what rustup-init does locally; the project itself remains pinned.

On your option 2 (`rustup-init` binary + sha256 verify) — I want to do it eventually but it has a hidden cost: the sha256 has to be refreshed on every rustup-init release. That's an extra maintenance burden that, for the kind of one-shot dev-host setup script this is, trades supply-chain hygiene for staleness (an operator running an old script with a wrong sha hits a hard fail and is more annoyed than helped). I'm tracking it as a possible `--paranoid` mode for a future contributor who wants to take it on; the comment block in the script flags it so the next person can find it.

Welcome — and looking forward to more 🚀