Hacker News new | ask | show | jobs
by jjgreen 1175 days ago
Written in Rust! Can you tell?

    curl --proto '=https' --tlsv1.2 -fsSL https://drop-sh.fullyjustified.net | sh
4 comments

Isn't it nice to get your software directly from the people who wrote it? At least I'm confident any malicious edits were made intentionally. If I add a distro middleman who knows what they messed up mucking around for no good reason.
Let’s say, for example, that I invite a friend over and offer them a glass of water. Would you be similarly upset to find that I don’t recommend that they first send a sample of the water to be tested for purity before consuming said glass of water? I mean, don’t get me wrong, I would be fine with my friend being cautious and wanting to get the water tested (though I doubt that would ever happen in practice)… but if he trusts me to give him clean water, I doubt you’d raise any fuss over him just downing a glass.

Why/how is this any different? Anyone that wants to inspect the shell script can amend that line to first save and view the script. Are you thinking it’s never appropriate to trust such a script implicitly? If that’s the case, I’d love to hear about your workflow for checking the packages you install (e.g. debs can run arbitrary post install scripts, and do you know that a malicious actor with signing keys didn’t taint the binaries therein?), how you inspect all JavaScript for sandbox escaping exploits before viewing anything on the web, how you’ve ensured your hardware itself isn’t backdoored, etc.

The complaints of piping directly into shell from an HTTPS server strikes me as nothing more than a “no real technologists does $THING!” sort of elitism, though I’m open to being shown otherwise. A non-answer would be to propose that one first fetch a package signing key and install from your package manager of choice — if the script we’re complaining about can’t be trusted, there’s no reason to trust that the key file is any better with it being hosted in exactly the same way… unless you’re going to propose that you use something along the lines of web-of-trust to inspire further confidence that the signing key is authentic; at that point, though, your problem is with how 99.9% of third-party software packages (with respect to your distro of choice) are distributed - every PPA I’ve ever seen (docker, mongodb, whatever) at best tells you to fetch a key from some HTTPS server, and that’s all. It would then strike me as suspect to single out curl|bash (while additionally implying something about Rust users).

   Anyone that wants to inspect the shell script can amend that line 
   to first save and view the script. 
They can, but they may well not get the same output since, as is well-known, curl | sh can be detected on the server.
I’m well aware of that. I didn’t make it explicit (as I thought it logically followed) that one would execute the local copy after review. Even putting aside the security aspect, downloading something twice makes little sense, so I thought the fact you would execute the saved file (again, after review) was pretty obvious.
Can't one do `curl $url | sh -c 'cat > /tmp/file'`?
No
Mind explaining why? I just tried it, and it works fine.
When we say "|sh can be detected on the server", this is not it. What you wrote is no different from `curl -o /tmp/file`.
also it is well-known that scripts you downloaded can be run locally
As a non-Rust person, mind explaining the comment to a layperson?
I believe u/jjgreen is complaining about the curl|bash pattern being used in a Rust codebase.
I think it's worth mentioning that the install line at https://www.rust-lang.org/tools/install looks exactly the same.
Yep, that's the joke.
Because safety is our #1 priority. Hah.