[HN Gopher] Show HN: Vet - A tool for safely running remote shel...
       ___________________________________________________________________
        
       Show HN: Vet - A tool for safely running remote shell scripts
        
       Author : a10r
       Score  : 30 points
       Date   : 2025-06-28 19:56 UTC (3 hours ago)
        
 (HTM) web link (getvet.sh)
 (TXT) w3m dump (getvet.sh)
        
       | a10r wrote:
       | 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
        
       | gardnr wrote:
       | This is a great idea!
       | 
       | One extra feature could be passing the contents of the shell
       | script to an LLM and asking it to surface any security concerns.
        
       | kevincox wrote:
       | 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.
        
         | a10r wrote:
         | 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.
        
       | a10r wrote:
       | Love the idea!
       | 
       | The two biggest hurdles for a security tool like this are LLM
       | non-determinism and the major privacy risk of sending code to a
       | third-party API.
       | 
       | This is exactly why vet relies on ShellCheck--it's deterministic,
       | rules-based, and runs completely offline. It will always give the
       | same, trustworthy output for the same input.
       | 
       | But your vision of smarter analysis is absolutely the right
       | direction to be thinking. I'm excited for a future where fast,
       | local AI models can make that a reality for vet. Great food for
       | thought!
        
       | 3abiton wrote:
       | This an amazing solution. I wondered about this often, looking at
       | you `uv`, but in a lot of the cases I cave given that everyone
       | else trust some code maintainers.
        
       | thealistra wrote:
       | Can you show how it works on the page or readme as a video?
       | 
       | Does it open pager or editor? How does it show the shellcheck
       | issues.
        
       | alganet wrote:
       | What if someone peppers their malicious script with `# shellcheck
       | disable=` pragmas?
        
       ___________________________________________________________________
       (page generated 2025-06-28 23:00 UTC)