Hacker News Reader

Comment by jjgreen | Hacker News Reader

Written in Rust! Can you tell?

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

View on HN

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.

also it is well-known that scripts you downloaded can be run locally

Can't one do `curl $url | sh -c 'cat > /tmp/file'`?

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`.

In other words, you are saying that an HTTP server can detect distinguish between when the client is doing `curl $url | sh`, and when the client is doing `curl $url | sh -c 'cat > /tmp/file'`.

I'd love to hear the mechanism that the server would use to do that, if you have the time!

I'm sorry I just saw this, but the idea is that sh will read as it executes so you can detect it passively. If you make it `sleep 1` you can detect on the server side that your call to send() hangs until sh proceeds, for the same duration as the sleep. You need to put enough content to make the TCP buffers fill up, but that can be done with all those function definitions that you tend to see in those scripts anyway.

Or the script could also signal through an active mechanism, a different innocuous-looking HTTP request that makes the server switch the content to a malicious payload if it happens at the same time.

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.

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.

Reply on news.ycombinator.com