I'll be happy to update it to suggest using rustup like "normal". Could you make a PR for that?
Depending on how you want to consider trust in a wider sense too it may even be worse than “double” because I do not have the same amount of trust for the package I am ultimately installing and the script I am using to install it.
Edit: it’s actually 3 things you need to trust I didn’t include curl itself which just released a security audit that found a number of vulnerabilities here https://daniel.haxx.se/blog/2022/12/21/the-2022-curl-securit...
…security is often harder than it looks.
No, you're still trusting one thing: the host itself. You're downloading both the script and the binary from the host. Both could be backdoored, and of the two, the binary is far easier to hide a backdoor in.
As for not trusting curl, you still need to fetch the resource somehow, so you're going to be trusting some tool to do it for you. That's not relevant to increasing the attack surface.
That clearly changes the trust calculation in this scenario.
I had assumed it was some 3rd party project which would have put it in a different category of problems entirely.
But the entire conversation is kind of pointless then. “There is a secret backdoor in the official Rust binary” is not a useful part of any reasonable threat model.
Technically, if you don’t read the script, you don’t know the binary is from the same host.
That doesn’t matter, though. The chain of trust is deep, including the tooling that produced the binary, your CPU, the internet, etc.
Downloading the first file basically says “I trust this site to give me this tool and nothing else”. Where it then gets that stuff from shouldn’t matter, even if it is from a shady site. You trusted them not to do that, just as you trusted them not to open up their own site so that hackers can replace files ont it.
I think the worst thing about this is that Rust is fashionable, so encouraging inexperienced devs think that these dangerous practices are just fine. Look around at how many n00b projects now suggest doing exactly the same thing. It's simply irresponsible of the Rust crowd to keep promoting it.
(BTW, you can run `curl | sh` in a VM or with a modified bash to intercept the code and catch the bash script in the act, so it's not actually as sneaky as people believe).
If you think the Rust org is going to pwn you in a clever sneaky way, then you can't use Rust or any Rust-containing products.
In the end, you're pulling hundreds of MBs of binaries that you won't review, they're compiled from over 15 million lines of code that I don't believe you'd ever review either. Reviewing just the first 10 lines of code gives you nothing. A smoke test in a sandbox is also worthless, since a binary could detect being run that way, or delay the attack, or attack by specifically miscompiling your code (see Reflections on Trusting Trust).
In the end, you have to trust the Rust org, all of it.
You're not wrong, until the end, it should be: "you have to distrust the Rust org, all of it."
And not just Rust, Python and JS and all the others. There are languages and systems that take trust and security seriously, but these are not they.
Anyway, off the top of my head, Ada.
https://en.wikipedia.org/wiki/Ada_(programming_language)
and E...
https://en.wikipedia.org/wiki/E_(programming_language) https://en.wikipedia.org/wiki/CapROS
Qubes and SEL4 are Operating systems. (OK Labs was acquired by General Dynamics. That seems like a pretty good recommendation to me.)
https://en.wikipedia.org/wiki/Qubes_OS
https://en.wikipedia.org/wiki/L4_microkernel_family#High_ass...
Most likely they get the precompiled rustc binary just like rustup, and LGTM-YOLO the package. If they try to be diligent, they maybe take extra 150K lines of mrustc code they can't reasonably carefully review for backdoors either, and then use it to bootstrap the several sets of 15M lines of code they won't look at.