It's hard to appreciate how good Rustls is at avoiding UaF since UaF avoidance is taken for granted in idiomatic Rust code. Tiny things like `#[must_use]` are small but help avoid big failures. Our friends doing concurrency & malloc/free in C are still struggling w/ the basics.
-
-
Replying to @BRIAN_____
Trying to write C/C++ after writing Rust feels ridiculous. Why should I have to keep track of things that the compiler can do for me, especially when the consequences are exploitable security bugs?
0 replies 1 retweet 9 likes -
Replying to @BRIAN_____ @TedMielczarek
For me the biggest annoyance is that Rust doesn’t have a wonderful solution for the most pernicious UAF in browsers: unexpected reentrancy from DOM into malicious JS. I don’t know that there *is* a good solution, really…
4 replies 0 retweets 7 likes -
Hm? The problem seems trivial: refcount references from JS to DOM, register all references from DOM to JS in a special GC root.
1 reply 0 retweets 0 likes -
Yeah, so the problem arises when, inside some native DOM implementation, you have a non-reference-counted pointer (reference) that persists across a function call that, unbeknownst to you, can call back into user JS and cause that reference to go dangling.
2 replies 0 retweets 1 like -
Because you skipped counting a reference...
1 reply 0 retweets 0 likes -
Like, for example in C++ the “this” pointer has to be a raw (non-RC’d) pointer. The language is hardwired to that.
2 replies 0 retweets 0 likes
It’s not a question of how to do it—it’s a trivial problem theoretically. It’s how to do it in a way that is ergonomic enough to scale up to a big DOM team.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.