Hacker News new | ask | show | jobs
by dicytea 340 days ago
I really never understood the threat model behind this often repeated argument.

Most of these installation scripts are just simple bootstappers that will eventually download and execute millions lines of code authored and hosted by the same people behind the shell script.

You simply will not be capable of personally auditing those millions lines of code, so this problem boils down to your trust model. If you have so little trust towards the authors behind the project, to the point that you'd suspect them pulling absurdly convoluted ploys like:

> the web server behind mywebsite.com/foo.sh provides malware for the first request from your IP, but when you request it again it will show a different, clean file without any code

How can you trust them to not hide even more malicious code in the binary itself?

I believe the reason why this flawed argument have spread like a mind virus throughout the years is because it is something that is easy to do and easy to parrot in every mildly-relevant thread.

It is easy to audit a 5-line shell script. But to personally audit the millions lines of code behind the binary that that script will blindly download and run anyways? Nah, that's real security work and no one wants to actually do hard work here. We're just here to score some easy points and signal that we're a smart and security-conscious person to our peers.

> which are hosted by microsoft, and therefore easily MITM'able by government agencies.

If your threat model includes government agencies maliciously tampering your Deno binaries, you have far more things to worry about than just curl | sh.

1 comments

I think bflesch's reasoning comes from the idea that the website developers may not hold their website to the same security standards as their software, and not from a trust issue. Nor from thinking the author themselves are malicious.

FWIW, I don't have a strong opinion here, besides that I like Debian's model the most. Just felt that it was worth to point out the above.

See the codecov incident, where exactly this happened: https://about.codecov.io/security-update/