Vet is a safety net for the curl | bash pattern

What vet does and why it exists

• vet is a wrapper around the curl | bash pattern: it fetches a remote script, shows it (with a pager/diff), and only runs it if the user explicitly confirms.
• Several commenters like it as a pragmatic harm‑reduction measure: you won’t stop people from using one‑liners, so you might as well make the default “inspect first, run second.”
• Others argue it adds minimal real security: you could already curl > file; less file; bash file, and vet doesn’t solve deeper supply‑chain problems.

Risk model: scripts vs binaries

• A recurring argument: if you don’t trust the project enough to run its install script, why do you trust the much larger, opaque binary it installs?
• Counterpoint:
  • Package managers add vetting, signatures, predictable file locations, and a clean uninstall story.
  • Install scripts often run as root, modify system paths, add repos, create users, open ports, or “yolo” into /usr/local or $HOME. That’s a different, more invasive risk than just running a single binary.
  • Even if both are arbitrary code, scripts can be poorly written and non‑standard, breaking systems in subtle ways.

Rust / rustup as a case study

• Rust’s official docs prominently recommend curl --proto '=https' ... | sh for installing rustup.
• One side calls this “crazy” for a language that markets safety.
• Others respond:
  • rustup itself can be (and is) packaged in many distros and Homebrew; the curl‑pipe is just a uniform, low‑friction option.
  • The real toolchain churn is in compilers and crates; rustup is stable enough for repos.
  • If you care, it’s possible to avoid curl|bash entirely by manually installing rustup, using distro packages, or tools like mise.

Server compromise & targeted curl|bash attacks

• People note that servers can detect “curl | bash” and selectively serve malicious payloads only to piped requests.
• Some argue this is mostly theoretical; others share real‑world phishing examples that use this trick.
• Consensus: once you trust a compromised server, both scripts and binaries are suspect; hashes or signatures from a separate channel are the only strong defense.

Sandboxing and alternatives

• Multiple suggestions: run installers in containers, VMs, separate users, or tools like firejail/bubblewrap; inspect filesystem diffs before adopting the result.
• Some point to Nix/Guix, Fedora Silverblue/distrobox, Flatpak, and similar approaches to isolate third‑party software, revert easily, and avoid curl|bash entirely.
• Others mention specific tools (e.g., try, probox) or workflows (devbox + nix, home‑manager) to never need curl | sh.

Culture, usability, and package management

• Many blame fragmentation and lagging distro repositories for the popularity of curl | bash: developers want a single, cross‑distro install, users want the documented “latest,” and packaging everywhere is hard.
• Others counter that this leads back to Windows‑style entropy: ad‑hoc installers that don’t integrate with the system, update weirdly, and rarely uninstall cleanly.
• Debate over “safer behavior”: some insist on “use your distro’s package manager first,” others say real‑world needs and outdated repos make curl|bash or custom repos unavoidable.

Critiques of vet and “security theater”

• Skeptical voices call vet “enterprise fizzbuzz” that mainly prettifies curl | bash without fixing core issues (trust, sandboxing, supply chain).
• Supporters respond that making the default path “review before execute” still meaningfully raises the bar, especially for copy‑paste one‑liner culture.