let's go through them in detail. issue (1): compilers have bugs. complex compilers have lots of bugs (https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3A%22I-unsound+%F0%9F%92%A5%22 …). many of those bugs are trivially exploitable with adversarial code (notably https://github.com/rust-lang/rust/issues/10184 …, https://github.com/rust-lang/rust/issues/28728 …), or with code that isn't…
-
-
Prikaži ovu nit
-
obviously incorrect in a way detectable with tooling (https://www.alchemistowl.org/pocorgtfo/pocorgtfo08.pdf#page=7 …). in other cases, expectations of support level, even though they are clearly stated, are misaligned with reality, notably tier 2 platforms universally lacking stack checks (https://rustsec.org/advisories/RUSTSEC-2020-0002.html …).
Prikaži ovu nit -
when I wrote https://github.com/m-labs/smoltcp/ , I made a prediction that, due to Rust's type system and #![deny(unsafe)], I will never have an exploitable issue -caused by the code I wrote for it-. I stand by it; note, however, that I am sure there are ways to exploit an application…
Prikaži ovu nit -
… through smoltcp (for example if you are using it in certain ways on ARM), and I had one benign soundness issue in smoltcp gone undetected due to a rustc bug. issue (2): memory-safe code isn't inherently better. to use a pathological example, a safe wasm interpreter in Rust…
Prikaži ovu nit -
… that runs ancient openssl inside is obviously exploitable. in a more realistic scenario, you might consider against using mem::uninitialized with incorrect reuse of cached buffers, introducing something very much like Heartbleed. issue (3): `unsafe` doesn't change Rust…
Prikaži ovu nit -
… all that much. even if you mark -all- of your code as unsafe, you still get the benefit of a rich type system, powerful compiler diagnostics, borrow checker, package ecosystem... which all help writing correct code! so, what is `unsafe` and what it isn't?
Prikaži ovu nit -
`unsafe` and the concept of safe code are merely tools that help you keep your code correct. they are, specifically, NOT a policy to be wielded as a blunt object. they are not designed for that and simply do not work that way in real life. not all unsafe code is unsound. not…
Prikaži ovu nit -
… all unsound code is unsafe. not all sound and safe code is correct, and it is quite easy to make it incorrect in a way that is dangerous similarly to unsound code. `#![forbid(unsafe)]` is only a tool among many to achieve correctness. stop the zealotry now; it's not helping.
Prikaži ovu nit
Kraj razgovora
Novi razgovor -
-
-
God, are people seriously trying to forbid unsafe across their codebase?
-
worse: they're trying to forbid unsafe across someone else's codebases, and in a rather hostile way. (I say this as someone who prides themselves on writing a 100% safe TCP/IP stack in Rust. there is a place for that, and a place for not doing it)
- Još 2 druga odgovora
Novi razgovor -
Čini se da učitavanje traje već neko vrijeme.
Twitter je možda preopterećen ili ima kratkotrajnih poteškoća u radu. Pokušajte ponovno ili potražite dodatne informacije u odjeljku Status Twittera.
