vet

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" 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.