4 ms·

> Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run a

> Several soundness issues were found in previous versions of the standard library that allow a malicious crate to take advantage of undefined behavior to run arbitrary machine code. It seems likely to me that there are similar unknown issues lurking in today's standard library or compiler. Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. I don't think there's any way to get around the social aspects of software security for most developers ("trusting _people_ not code")

binary132 3y ago
And yet hardly anyone ever makes this argument against sandboxing the code we download on demand every single day while browsing the internet. I have started to believe we should think of open-source software as not so different, and sometimes even as less trustworthy in certain ways since we typically don’t sandbox it. How many of your tools have telemetry? How many of your drivers do? How many download and execute stuff on the fly?
- tentacleuno 3y ago
  That's completely different, though. JavaScript is sandboxed (and a lot of effort goes into ensuring that), while build-time macros (and runtime code) runs on the machine in an unrestricted manner. Not sure what your point is.
fleventynine 3y ago
> Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. The idea here is that if the "evil crate" is prevented by the compiler to call out into any os functionality or use unsafe, the worst it can do is return bogus values, mutate anything it has a &mut reference to, and leak heap memory. And if the toolchain were perfect, that might be achievable. This was the promise that Java Applets made, which wasn't achievable due to the JVM being too bug-prone.

binary132 3y ago

And yet hardly anyone ever makes this argument against sandboxing the code we download on demand every single day while browsing the internet. I have started to believe we should think of open-source software as not so different, and sometimes even as less trustworthy in certain ways since we typically don’t sandbox it. How many of your tools have telemetry? How many of your drivers do? How many download and execute stuff on the fly?

tentacleuno 3y ago
That's completely different, though. JavaScript is sandboxed (and a lot of effort goes into ensuring that), while build-time macros (and runtime code) runs on the machine in an unrestricted manner. Not sure what your point is.

fleventynine 3y ago

> Even without any soundness issues or bugs or security flaws, people can just plain write malicious code. Rust prevents a lot of common _mistakes_, but people can also use it to write completely "safe" worms that are guaranteed not to have use-after-free errors, data races and unexpected panics. The idea here is that if the "evil crate" is prevented by the compiler to call out into any os functionality or use unsafe, the worst it can do is return bogus values, mutate anything it has a &mut reference to, and leak heap memory. And if the toolchain were perfect, that might be achievable. This was the promise that Java Applets made, which wasn't achievable due to the JVM being too bug-prone.