Earlier quoted context omitted.
Are you okay?
Better than you
who's you?
Malicious Rust crate Arrayref runs a build-time payload
521–527 of 527 posts
Re: Malicious Rust crate Arrayref runs a build-time payload
#522Earlier quoted context omitted.
So, don't add dependencies before you audit the code? That seems like a pretty reasonable ask to me.
You audit the code, then you run cargo update and you are pwned. Asking the user to not make mistakes is the c++ approach to security - it doesn’t work.
You're creating a strawman. Don't run cargo update without verification, duh.
> Asking the user to not make mistakes is the c++ approach to security
Then demand crates.io do better by actually curating every version of every published crate.
Re: Malicious Rust crate Arrayref runs a build-time payload
#523Earlier quoted context omitted.
There's no good reason a proc macro can't run in a no-IO sandbox by default. None. Doesn't require a language change. Doesn't require some microvmcapabilityeffect BS. It requires looking people straight in the eye and saying "no" when they complain about needing to prompt for privileges.
No good reason? Here's a list: https://github.com/dtolnay/watt#remaining-work (It mostly boils down to "somebody needs to do it". I'd really like proc macros precompiled to wasm by crates.io…)
WASM is totally unnecessary. Vanilla seccomp is sufficient and runs at full performance. What is it with people trying to stick WASM in places it's not needed?
Re: Malicious Rust crate Arrayref runs a build-time payload
#524Earlier quoted context omitted.
I'm not sure what namespacing has to do with anything here. Namespacing would not even remotely have prevented anything like the OP.
It would make it easier to, as a matter of policy, to stick to components from teams like boost or Apache or Google, i.e. groups with known reputations, reputations for having long-term, active involvement and maintenance than crates put out by single individuals or startups. And if and when a project was compromised, it's more likely to be discovered in a timely manner. To build reputations (good or bad), an ecosyst…
And yet it remains true that, in fact, namespacing would not have prevented anything here. And I say that as someone who is in favor of namespacing.
Re: Malicious Rust crate Arrayref runs a build-time payload
#525Earlier quoted context omitted.
`cargo add` just modifies your Cargo.toml, it doesn't build anything.
https://shnatsel.medium.com/do-not-run-any-cargo-commands-on... > any command starting with cargo can run arbitrary code when operating on an untrusted repository, and should be treated the same as cargo run.
This comment is both true and entirely irrelevant. The context of this subthread is not running a Cargo command in a checkout of a malicious git repo, it's alleging that `cargo add foo` runs the build script of the crate `foo`, which is false.
Re: Malicious Rust crate Arrayref runs a build-time payload
#526Earlier quoted context omitted.
Rust, like C, C++, and every other systems programming language, is all about giving users the power to make mistakes. The philosophical difference when it comes to Rust is simply that it tries to force the user to flip off the safety on the gun before letting you shoot yourself in the foot. A Cargo config option letting people opt-out of sandboxing would be fully in line with Rust's philosophy.
Having a dangerous flag as a backwards compatibility flag is okay. I don’t think making users decide between multiple levels of sandboxing is constructive, they will just be trained to ignore it. This is the kind of decision users likely don’t understand without looking at the source code of a crate and it’s bad UX to push it to be their responsibility.
No, the flag would not exist simply for backwards compatibility, it would exist because build scripts are occasionally necessary and there are plenty of legitimate uses for them, even if they should be opt-in.
Re: Malicious Rust crate Arrayref runs a build-time payload
#527Earlier quoted context omitted.
ABI stability is significantly different in a VM language to a native language, and reified generics necessarily require source compilation. Binary-only development for Rust would be exactly as 'sort of not really' as C++, for exactly the same reasons. (There is also no notion of 'installing' dependencies in Rust, and build-time code being malicious isn't much worse than runtime code being malicious.)
But people say build.rs is used mostly to compile C dependencies, in which case the lack of ABI stability of Rust is neither here nor there.
It's used to do all sorts of things. Rust version probing, bindings generation, precompiling bundled data, etc. The only reason it isn't used to do more is because proc macros do it instead, with an essentially identical execution model and sandboxing situation (ie build scripts in isolation are a red herring).