4 ms·

Hi HN, I'm the creator of `vet`. I've always been a bit nervous about the `curl | bash` pattern, even for trusted projects. It feels like there's a missing safe

by a10r 1y ago

Hi HN, I'm the creator of `vet`. I've always been a bit nervous about the `curl | bash` pattern, even for trusted projects. It feels like there's a missing safety step. I wanted a tool that would show me a diff if a script changed, run it through `shellcheck`, and ask for my explicit OK before executing. That's why I built `vet`. The install process itself uses this philosophy - I encourage you to check the installer script before running it! I'd love to hear your feedback. The repo is at https://github.com/vet-run/vet https://github.com/vet-run/vet

__MatrixMan__ 1y ago
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 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 1y ago
  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__ 1y ago
    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.
geocar 1y ago
> I wanted a tool that would show me a diff if a script changed, run it through `shellcheck` Why? What exactly do you think "shellcheck" does? When do you think you're diffing and what do you think you are diffing with? > and ask for my explicit OK before executing. But to what end? You're not better informed by what the script does with this strategy. A small shell script like yours I can read in a minute and decide it does nothing for me, but large installers can be hard to decipher since they are balancing bandwidth costs with compatibility, and a lot of legitimate techniques can make this hard to follow without care and imagination. > The install process itself uses this philosophy - I encourage you to check the installer script before running it! I don't understand what philosophy you're talking about. I think you're doing the exact same thing that malicious attackers do, you're just doing it worse: $ wget -qO- https://getvet.sh --2025-06-29 05:22:26-- https://getvet.sh/ Resolving getvet.sh (getvet.sh)... 2a06:98c1:3120::5, 2a06:98c1:3121::5, 188.114.97.5, ... Connecting to getvet.sh (getvet.sh)|2a06:98c1:3120::5|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘STDOUT’ <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> I mean your script knows about wget, but your server doesn't. Sad. I also think you should be telling people to pull "https://github.com/vet-run/vet/blob/main/scripts/install.sh https://github.com/vet-run/vet/blob/main/scripts/install.sh" instead of trying to be cute, but that's just me. > I'd love to hear your feedback. You're getting it: I think your program sucks, but I also like the idea of trying to do something, and I understand you just don't have any idea what to do or what the problem actually is. So let me teach you a little bash: check () { echo "> $BASH_COMMAND" >&2 echo -n "Allow? (yes/no) " >&2 select c in yes no do if [ "$c" = "yes" ] then break elif [ "$c" = "no" ] then return 1 fi done } shopt -s extdebug trap check DEBUG This little scriptlet will wait until bash tries to run something, and ask before proceeding. Simples. Put this in front of an installer (or something else messy) and get step-by-step confirmation of what's going on. Something like this is in the BASH manual someplace, or was once upon a time. In a large script this might annoy people, so if it were me, I would have a whitelist of commands that I think are safe, or maybe a "remember" option that updates that script. I might also have a blacklist for things like sudo. While I'm on the subject of sudo, a nasty trick bad guys use is get you to run sudo on something innocuous and then rely on the cached credentials to run a sneaky (silent) sudo in the same session. Running sudo -k before interacting with an unknown program can help tremendously with this.
BaudouinVH 1y ago
The idea is great. Vet will work for people who can run the code displayed. Right now my skills are not high enough. Unsure wether I sit with the majority or minority of future users. My 2 cents
subjectsigma 1y ago
I appreciate you finding a problem and trying to build a solution, but I think your solution will not work very well. Shellcheck is not a virus or vulnerability scanner, it’s not designed for the thing you are using it for.
- a10r 1y ago
  You are absolutely right, and that's a crucial distinction to make. ShellCheck is a linter, not a security scanner. Its role in vet isn't to find malware, but to act as an automated code quality check. A script full of shellcheck warnings is a red flag, which helps inform the user's final decision to trust it or not. It's one of several signals that vet provides. Thanks for the important clarification!

by a10r 1y ago

__MatrixMan__ 1y ago

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 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 1y ago
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__ 1y ago
  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.

geocar 1y ago

> I wanted a tool that would show me a diff if a script changed, run it through `shellcheck` Why? What exactly do you think "shellcheck" does? When do you think you're diffing and what do you think you are diffing with? > and ask for my explicit OK before executing. But to what end? You're not better informed by what the script does with this strategy. A small shell script like yours I can read in a minute and decide it does nothing for me, but large installers can be hard to decipher since they are balancing bandwidth costs with compatibility, and a lot of legitimate techniques can make this hard to follow without care and imagination. > The install process itself uses this philosophy - I encourage you to check the installer script before running it! I don't understand what philosophy you're talking about. I think you're doing the exact same thing that malicious attackers do, you're just doing it worse: $ wget -qO- https://getvet.sh --2025-06-29 05:22:26-- https://getvet.sh/ Resolving getvet.sh (getvet.sh)... 2a06:98c1:3120::5, 2a06:98c1:3121::5, 188.114.97.5, ... Connecting to getvet.sh (getvet.sh)|2a06:98c1:3120::5|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ‘STDOUT’ <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8" /> I mean your script knows about wget, but your server doesn't. Sad. I also think you should be telling people to pull "https://github.com/vet-run/vet/blob/main/scripts/install.sh https://github.com/vet-run/vet/blob/main/scripts/install.sh" instead of trying to be cute, but that's just me. > I'd love to hear your feedback. You're getting it: I think your program sucks, but I also like the idea of trying to do something, and I understand you just don't have any idea what to do or what the problem actually is. So let me teach you a little bash: check () { echo "> $BASH_COMMAND" >&2 echo -n "Allow? (yes/no) " >&2 select c in yes no do if [ "$c" = "yes" ] then break elif [ "$c" = "no" ] then return 1 fi done } shopt -s extdebug trap check DEBUG This little scriptlet will wait until bash tries to run something, and ask before proceeding. Simples. Put this in front of an installer (or something else messy) and get step-by-step confirmation of what's going on. Something like this is in the BASH manual someplace, or was once upon a time. In a large script this might annoy people, so if it were me, I would have a whitelist of commands that I think are safe, or maybe a "remember" option that updates that script. I might also have a blacklist for things like sudo. While I'm on the subject of sudo, a nasty trick bad guys use is get you to run sudo on something innocuous and then rely on the cached credentials to run a sneaky (silent) sudo in the same session. Running sudo -k before interacting with an unknown program can help tremendously with this.

BaudouinVH 1y ago

The idea is great. Vet will work for people who can run the code displayed. Right now my skills are not high enough. Unsure wether I sit with the majority or minority of future users. My 2 cents

subjectsigma 1y ago

I appreciate you finding a problem and trying to build a solution, but I think your solution will not work very well. Shellcheck is not a virus or vulnerability scanner, it’s not designed for the thing you are using it for.

a10r 1y ago
You are absolutely right, and that's a crucial distinction to make. ShellCheck is a linter, not a security scanner. Its role in vet isn't to find malware, but to act as an automated code quality check. A script full of shellcheck warnings is a red flag, which helps inform the user's final decision to trust it or not. It's one of several signals that vet provides. Thanks for the important clarification!