[__MatrixMan__]

I'm glad to see that I'm not the only person worried about this. It's a pretty glaring bit of attack surface if you ask me. I chuckled when I saw you used nvm as an example in your readme. I've pestered nvm about this sort of thing in the past (https://github.com/nvm-sh/nvm/issues/3349).

I'm a little uncertain about your threat model though. If you've got an SSL-tampering adversary that can serve you a malicious script when you expected the original, don't you think they'd also be sophisticated enough to instead cause the authentic script to subsequently download a malicious payload?

I know that nobody wants to deal with the headaches associated with keeping track of cryptographic hashes for everything you receive over a network (nix is, among other things, a tool for doing this). But I'm afraid it's the only way to actually solve this problem:

1. get remote inputs, check against hashes that were committed to source control

2. make a sandbox that doesn't have internet access

3. do the compute in that sandbox (to ensure it doesn't phone home for a payload which you haven't verified the hash of)

[charcircuit]

Vet only downloads once, so what do you mean by subsequent download?

Also hashing on inputs is brittle and will break anytime the developer pushes an update. You want to trust their certificate instead.

[__MatrixMan__]

After looking closer, I think I misunderstood. I thought that after a human reviewed the script, vet would cache something which indicates that that script is trusted--that way it can run in CI without a human involved, and vet is checking that it is indeed the thing the human trusted. Looks like not.

Re: hashes, the whole point is that I want it to break anytime the developer pushes an update, that's my cue to review the update and decide once more whether I want it in my project. The lack of awareness re: what that curl is going to provide is the whole reason people think that `curl | bash` is insecure.

Otherwise there's no commit which indicates the moment we started depending on the new version--nothing to find if we're later driving `git bisect` to figure out when something went wrong. It could supply a malicious payload once, revert back to normal behavior, and you'd have no way to notice.

Also, you end up with developers who have different versions installed based on when they ran the command, there's no association with the codebase. That's a different kind of headache.