5 ms·

While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without

While it is likely that the issue affecting OpenSSL is memory safety related, how do you know for sure that it is and that rust would have prevented it without having a performance impact? While a language which prevents certain memory errors by design is going to be safe by design, it's entirely possible this bug is in code so hot that it has been repeatedly optimized further and further and that an equivalent implementation in rust would require an unsafe block. Now it is all great to respond to this by saying "safety should never preclude performance" but in that case, why would you write in rust when there are even safer languages such as spark? Moreover, if your secure solution is too slow, nobody will want to use it. I do agree that OpenSSL is a pile of trash, but an overwhelming amount of the crust of OpenSSL is not C related.

29athrowaway 4y ago
> While it is likely that the issue affecting OpenSSL is memory safety related It always is. Because it's a C project where memory management is done manually. And everything done manually is subject to human error. Doing C-style a capella memory management in 2022 is not necessary. > how do you know for sure that it is and that rust would have prevented it without having a performance impact Because much of the safety features Rust implements for memory management happens at compile time not at runtime.