|
| ▲ | gejose 5 hours ago | parent | next [-] |
| It might not be a magic security wand, but so many critical vulnerabilities in software trace their origins to memory unsafe code and things like "use after free". "~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" - Microsoft [1] "We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code." - Google on Android [2] This is also worth looking: https://www.chromium.org/Home/chromium-security/memory-safet... References:
1. https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactiv...
2. https://blog.google/security/rust-in-android-move-fast-fix-t... |
| |
| ▲ | anthk 5 hours ago | parent [-] | | If I were Google I'd try to rewrite Chromium in Rust. The FFMPEG folks should try porting the whole codebase to Rust too. They can always keep the legacy versions for legacy computers (my old n270 netbook can barely play 720p@30FPS anyway, and it's too slow to downsize 4k video to 720 or 480p...), so a bigger amd64 machine will always be -reallistically- needed for anything else than <=720p consumption. | | |
| ▲ | nkjoep 4 hours ago | parent [-] | | What folks at Ladybird did this year. Started adopting rust for part if not all their engine. |
|
|
|
| ▲ | mr_toad 3 hours ago | parent | prev | next [-] |
| No, but it was created to mitigate these sorts of risks. |
|
| ▲ | wat10000 2 hours ago | parent | prev | next [-] |
| It kind of is, as is any other memory safe language. You certainly can still write security vulnerabilities that don't involve memory safety violations, and these languages always have unsafe escape hatches that you can use to shoot yourself in the foot. But as long as you don't just sprinkle unsafe on everything, using a safer language is going to make a ton of vulnerabilities just disappear. Looking at the issues from this past week, safe languages won't stop you from using 4 as your private key, but they would have entirely prevented the PHP vulnerability. |
|
| ▲ | anthk 5 hours ago | parent | prev [-] |
| It cuts down most of the crap trying to trash your machine's RAM (virtual memory in the end, but today it's almost as if you didn't have a MMU). It's good enough. On less powerful machines, dear Mutt+isync+msmtp users like me, please use AERC (written in Go) against these. It's slower, but far more secure than C.
Also, SLRN needs a Go rewritten clone (able to point to slrn's caché) like nothing else. Comp.misc and comp.arch still are extremely valuable. |
