And where is this trust supposed to come from? I downloaded the thing manually, looked at the scripts, ran the binary in a sandbox, it seemed to be OK. Right, I'll recommend that everyone just curl | bash's 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.
The bash timing exploit makes everyone focus just on how cleverly evil it can be, and forget the big picture that it's about trusting the Rust org not to screw you.
(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.
(Is it that you don't know of any yourself? Or that you think I can't provide examples? In what world is what I said even slightly controversial? Type checking is just catching on now, decades after it was invented and implemented. C'mon.)
"Trusting the Rust org not to screw you" is one part, another part is trusting the Rust server operators to defend against server compromise by any third party. So trusting the intentions is not sufficient.
The same thing applies to any binaries downloaded from their site, so unless you you've got signed binaries (that use an independently obtained/verified chain of trust), trusting the server is your your only option. Even with signed binaries, you're still trusting the entity that holds the signing key.
In real world trust is not so binary. In a risk assessment I'd be interested evaluating the level of assurance there is in the supply chain of how you get your binaries and artifacts. Some of it can be done using crypto like you say, some of it could be eg published audit reports from a reputable evaluator or other credible information about the processes.
