Hacker News Reader

> Auditing the script won't help you, because it'll say it will install a program somewhere. Which is what you want, so you'll consider the audit "ok" [but that program is made by the same people as the installation script].

Your argument doesn't take into consideration that build artifacts / software releases have culture and best practices behind them. Such releases are often considered, tested, cut, digested, signed and included in package managers delegating trust.

Many one-off installation shell scripts are not afforded that culture, especially when maintained from within (static) websites that update frequently. On the other hand, they are small enough for you to audit a bit. If you'd compare the script with one that someone else downloaded a month earlier (i.e. archive.org), that would help a lot to establish trust.

> If we ignore the idea of downloading and building every program from source

Your argument is equally valid when building every program from source. You will not be able to review the source code of moderately large programs. You will need to delegate your trust in that case as well.

It always comes back to trusting trust [1].

[1]: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

And the response to that: https://dwheeler.com/trusting-trust/

To me, the problem has never been that you're running a shell script from some remote source, but that you're expected to pipe it directly into an interpreter so the existence of what you actually ran is ephemeral.

There are the various levels of trust that you need to account for, but as you and others bite, that isn't specifically different to most people than some installer.

What is different is that there's no record of what you ran if you pipe it to an interpreter. If, later, you want to compare the current script available against what you ran, there's no easy way.

Nothing prevents you from doing

    curl > install.sh
    less install.sh
    sh install.sh

Yes, that's the point. You can, and probably should do that, but the guides don't bother with what is essentially making one command two because two commands is one more for someone to screw up.

I think the trade off they are taking is fundamentally a bad one with respect to security and accountability. It's not even about checking the script ahead of time. It's about checking what was actually run at a later date to see what happened. If the script is never stored to disk, determining whether a short lived hack of the script source affected you is much harder.

No, they don't bother because most people won't understand the script anyway, and just rely on the fact that many people have installed Rust this way and nothing bad happened to them.

You don't need to understand the script to have it in the directory and run a sha1 or md5 against it, and compare it against what should have been returned when there's an announcement that there was a problem.

That is what I mean by accountability. When nothing is left on disk of what was specified to execute, there's severely limited recourse in figuring out what happened.

I'm not suggesting every person does:

    curl > install.sh
    less install.sh
    sh install.sh

I'm suggesting they should be directed to do:

    curl > install.sh
    sh install.sh

and then later if there's a known problem, there are fairly easy ways for them (even a novice) to determine whether what they ran was legitimate or not. Piping a web request directly to a shell is a poor trade off WRT security to request of anyone, IMO. By that I mean that the gain in ease of use is extremely small, but the loss in accountability is fairly large in the case that there's a problem.

With the other languages the apps on my machine are built with (C, and to a large degree Python) I have the benefit of the distribution maintainers at least looking in the general direction of the source for things I install (including development libraries.) Tools like Cargo shortcut that and open me up to a lot of nastiness. It's very similar to the problem on Windows really and I wouldn't be surprised if you started seeing malware disturbed that way like we're currently seeing on NPM and Pypi.

rustup in particular is well-behaved. It installs itself in a single directory, without modifying the system, apart from PATH which it warns you about, lets you skip it, and when it does it, it does with care.

OTOH many distros don't take care to build and package Rust properly. For example, Rust patches its version of LLVM to avoid known bugs. The particular combination of Rust version + LLVM version is most tested. Distros that insist on unbundling build Rust with a stock LLVM that doesn't have these bugfixes, and often is an older version of LLVM that hasn't been thoroughly tested with Rust.

Then there's the mismatch of upgrade approach between the Rust project and most distros. Rust uses an "evergreen" (Chrome-like) approach to upgrades, in which the focus is on making upgrades seamless and not breaking anything so that they can be small and frequent. Most distros prefer infrequent big upgrades, so they package unusably old and officially unmaintained versions of Rust for no good reason.

This is threat modeling. Bunnie Huang's threat model for Precusor is considerably more stringent than the ordinary, to put it mildly.

Compare this to a C program where love it and hate, it's just a bunch of files that get included by concatenation. There's no magic to make your life easier or get you in trouble, everything is done via manual transmission.

The article goes into why they haven't been able to apply this approach to Rust, even though they would like to.

Auditing the script can certainly help, just not against malice. E.g. if the script is not set up in such a way that it protects against partial execution, then this represents a kind of vulnerability (truncation) that signed MSI/.deb/etc files simply do not, by the design of the file format.

Yes, it's possible (even easy) to write a curlbash script that doesn't have this issue (or the various other issues). Reviewing the script still buys you something.