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

(getvet.sh)

89 points a10r | 1 comments | 28 Jun 25 19:56 UTC | HN request time: 0.302s | source

Show context

kevincox ◴[28 Jun 25 20:43 UTC] No.44408014[source]▶

My main question is in 90% of cases these are installers. How are you actually verifying the software that you install? In some cases it is signed and verified but in many cases it is just coming down from the same HTTPS server with no additional verification. So are you then diffing the code (which may be compiled) as well?

I'm not saying that random running random installers from the internet is a great pattern. Something like installing from your distribution can have better verification mechanisms. But this seems to add very little confidence.

replies(3): >>44408170 #>>44409862 #>>44410375 #

shivawu ◴[29 Jun 25 02:22 UTC] No.44409862[source]▶

>>44408014 #

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”

replies(1): >>44415345 #

1. sgarland ◴[29 Jun 25 18:46 UTC] No.44415345[source]▶

>>44409862 #

This. OP, tools often install their own update mechanisms (e.g. `uv self update`), so this may not be as useful as you think. As an alternative (albeit one that adds potential hosting costs), consider running a small DB - can be as simple as SQLite - with hashes of scripts. You also need to handle legitimate updates from the script's author[s], though. If you can extract versioning from the URL, e.g. GitHub releases, you could include that in the schema.

I made a gist demonstrating a SQLite schema and using it via direct user input: https://gist.github.com/stephanGarland/5ee5281dedc3abcbc57fa...

↑