Show HN: Vet – A tool for safely running remote shell scripts

You're absolutely right—vet's scope is focused on securing the installer script itself, not the binary it downloads.

The goal is to prevent the installer from being maliciously modified to, for example, skip its own checksum verification or download a binary from a different, malicious URL.

It's one strong link in the chain, but you're right that it's not the whole chain.

The other thing is.. installer generally only runs once on a single machine, not sure how useful it is to “show the changes since last run”

> How are you actually verifying the software that you install?

By installing it through a well-audited, cryptocraphically-signed and community-maintained package list with a solid security history. What?

The bug here isn't that "it's hard to make downloading scripts secure!", it's that people on macs (and a few other communities, but really it's just OS X culture at fault here) insist on developing software with outrageous hackery like this and refuse to demand better from their platform.

Fix that. Don't pretend that linting (!!) shell scripts pulled off the open internet is going to do anything.

Great point.

A malicious actor could definitely do that. That’s why vet’s model doesn’t rely solely on ShellCheck—it’s just one layer. The key layer here is the diff. Even if the linter is silenced, the diff reveals any new suspicious # shellcheck disable= lines added to trusted scripts. That change alone is a red flag.

I guess you stopped reading there and missed that part:

> Yes, we see the irony! We encourage you to inspect our installer first. That's the whole point of vet. You can read the installer's source code install.sh

What are you thinking related to uv?

You're right, the README explains what vet does, but it doesn't do a great job of showing how it feels to use it. I'll definitely create a demo GIF for the page.

To answer your questions directly in the meantime:

- Pager or Editor? It opens a pager (less by default, but it will automatically use the much nicer bat if you have it installed for syntax highlighting). It doesn't open an editor to prevent any accidental modifications.

- ShellCheck Issues: If shellcheck finds issues, it prints its standard, colorful output directly to your terminal before you review the script. It then pauses and asks you if you want to proceed with the review despite the warnings, like this:

==> Running ShellCheck analysis...

In /tmp/tmp.XXXXXX line 7: echo "Processing file: $filename" ^-- SC2086: Double quote to prevent globbing and word splitting.

==> WARNING: ShellCheck found potential issues. [?] Continue with review despite issues? [y/N]

Thanks again for the excellent idea!

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)

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

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

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.

And this is why this exploit mechanism works so well.

Most installers are doing the same basic patterns: checking for dependencies, checking the distro, etc. It’s not hard to figure these out and spot them in different scripts.