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
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
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" 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.
First, let me address the bugs you found, because you were 100% right. The wget user-agent issue revealed a significant and regrettable flaw in the server-side logic. Thanks to your report, a fix has already been merged and deployed.
The installer also had a conceptual flaw in its security recommendation, as you and others pointed out. The documentation has been updated to recommend a two-step "download, then execute" process and now includes a direct link to the GitHub release asset for maximum transparency—no more "cute" domain magic as the primary method.
Your trap DEBUG suggestion is a really powerful technique, and it highlights a core philosophical difference in how to approach this problem:
Your approach is an "In-Flight Monitor"—it steps through an executing script and asks for permission at each step. It's fantastic for deep, real-time analysis.
vet's approach is a "Pre-Flight Check"—its goal is to let a human review and approve a complete, static snapshot of a script before a single line of it ever executes.
I chose the "pre-flight" path because diffing and shellcheck are central to the idea. They answer the questions: "I trusted this script last month, but has it changed at all since then?" and "Does this static code contain any obvious red flags?"
The trap DEBUG method is powerful, but it can't answer that "what's changed?" question upfront and runs the risk of "prompt fatigue" on large installers, where a user might just start hitting 'y' to get through it.
You've given me a lot to think about, especially on how to better articulate this philosophy. I sincerely appreciate you taking the time to teach and challenge the project. This is the kind of tough, expert feedback that makes open source better, and you've already had a direct, positive impact on it.