Verify before you run

For the sysadmin or DevOps operator who has typed curl -sSL example.com/install.sh | sudo bash more times than they’d like to count, and half-knew each time that it wasn’t right.

Four short reads, spaced three days apart if you want a course pace — or read straight through in one sitting. Each stands alone; taken together they give you a repeatable download → verify → read → run workflow that takes an extra thirty seconds and closes the supply-chain gap almost every casual install currently leaves open.

After this series: you can verify a GPG-signed script from any publisher; you can read a GitHub repo and tell whether it’s the thing you think it is; and you have run a real script that way, end to end, using the StackHarden Hardening Audit script as the worked example.

Why `curl | bash` is the wrong default

The install instructions for rustup, Homebrew, nvm, Docker, most Kubernetes tooling, most observability agents, and thousands of smaller projects share a single opening line: 1curl -sSL https://example.com/install.sh | sudo bash Most operators run it. Most operators know, dimly, that they probably shouldn’t. This series is about what “probably shouldn’t” actually means, and about a workflow that gives you the convenience of a one-liner without the trust-me-bro leap of faith. NIS2 · Article 21(2)(d) Supply-chain security. Regulators expect controls over software acquisition — unverified curl | bash is exactly the failure mode Article 21(2)(d) was written about. What can actually go wrong Four failure modes, ordered by realism. None of them are hypothetical. ...