every curl | sh install script has the same problem.
not “it runs untrusted code.” you clicked the link. you trust the project. the problem is subtler.
sha256 checksums verify that what you downloaded matches what the server said you’d get. if the server is compromised, the attacker serves their binary and a matching hash. your sha256 check passes. you run their code.
we added a second layer.
the release pipeline now signs every binary with an ed25519 key. the public key is baked into brr at build time. to verify a signature, you need the public key. to forge one, you need the private key. the private key never touches the CDN.
the check in install.sh looks like this:
brr verify-release ./brr-daemon "$SIG_DAEMON"brr checks the signature against its pinned key. if it doesn’t match, it deletes the file and exits. the binary never runs.
there’s a bootstrapping problem. macOS doesn’t ship a usable ed25519 verifier in shell. LibreSSL is present but doesn’t support the algorithm. python3 prompts the Xcode CLT installer on a fresh machine.
so we use two stages.
stage 1: download brr. verify it with sha256 over TLS. this is vulnerable to a compromised server, same as before.
stage 2: once brr is on disk and sha-anchored, use it to verify itself and the other binaries. the ed25519 check runs from this point forward.
the residual is explicit in the install script: a swapped stage-1 brr that matches its sha256 is irreducible in shell. the trust root is TLS, same as the script itself. we wrote it down rather than pretend it’s solved.
this has been stable for five days. no churn on the surface.
what changed: strangers who run the install script on a fresh machine get two layers of verification instead of one. the second layer doesn’t depend on our infrastructure being intact.
the first stranger who runs it on a compromised CDN won’t notice anything different. that’s the point.