ripgrep is so cool; we need more basic utilities reimagined for modern use cases and reimplemented in languages that aren't security disastershttps://github.com/BurntSushi/ripgrep/releases/tag/11.0.0 …
-
-
-
Replying to @johnregehr @vyodaiken
Howard Chu Retweeted RustSec
Yes it does. https://mobile.twitter.com/RustSec/status/1031908818936987650 … In both C and rust, braindead libraries can break your program.
Howard Chu added,
2 replies 0 retweets 1 like -
Howard Chu Retweeted Howard Chu
And it's easy to make bulletproof libraries to replace the shitty standard libraries in C.https://mobile.twitter.com/hyc_symas/status/1102573036534972416 …
Howard Chu added,
2 replies 0 retweets 0 likes -
The difference is that nothing stops people from passing bad pointers into your "bulletproof" strcpy. Absence of undefined behavior in Rust can be verified (formally or otherwise) at unsafe module boundaries; the same verification can only be done at *process* boundaries in C.
1 reply 0 retweets 9 likes -
Replying to @awesomeintheory @hyc_symas and
Since in most Rust repositories (including ripgrep) the amount of unsafe code is orders of magnitude smaller than the amount of code running in the process, this is a pretty significant practical win. Empirically, Rust's stdlib has had *very* few CVEs since it became stable.
1 reply 0 retweets 7 likes -
Shouldn't the amount of unsafe code in a simple user app that scans files for regexps be *zero*? If the language "doesn't have buffer overflows" shouldn't the number of library CVEs have always been zero?
3 replies 0 retweets 0 likes
I don't think anyone has ever filled a buffer overflow bug against ripgrep. ripgrep has only two uses of unsafe now. One of them is for disabling pcre2 slow utf8 checking when possible. The other for is enabling file backed memory maps.
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.