a10r

You are absolutely right, and that's a crucial distinction to make. ShellCheck is a linter, not a security scanner.

Its role in vet isn't to find malware, but to act as an automated code quality check. A script full of shellcheck warnings is a red flag, which helps inform the user's final decision to trust it or not. It's one of several signals that vet provides.

Thanks for the important clarification!

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!

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.

That’s an excellent point, and thank you for raising it. You are 100% correct—relying on users to inspect a URL that could be spoofed with User-Agent trickery is a flaw in the original recommendation. It's a classic threat model that I should have addressed from the start.

Thanks to your feedback, I've just merged a PR to change the recommended installation method in the documentation to the only truly safe one: a two-step "download, then execute the local file" process. This ensures the code a user inspects is the exact same code they run.

I sincerely appreciate you taking the time to share your expertise and hold the project to a higher standard. This is what makes a community great.

Wow, thank you for taking the time to write such a detailed and in-depth critique.

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.

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.

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!