Re:OpenSSL will release a high-severity issue fix on 25th
by tptacek on Monday March 22, 2021 @07:38PM
(#26549001)
If you're looking for me to argue with you that C is an acceptable substitute for languages like Rust and Go, you're barking up the wrong tree. It's not. But that doesn't mean we can simply bucket every vulnerability in a memory-unsafe program as a casualty of memory-unsafety, especially in programs like OpenSSL, which host a large domain of other vulnerabilities that are equally present in Rust and Go code.
[ Parent
| on HN ]
Re:OpenSSL will release a high-severity issue fix on 25th
by bluejekyll on Monday March 22, 2021 @10:46PM
(#26550427)
Not looking for an argument, just trying to incorporate some more perspective.
Re:OpenSSL will release a high-severity issue fix on 25th
by tptacek on Monday March 22, 2021 @11:02PM
(#26550534)
Cryptography might be the one single place where I'd look askance at replacing memory-unsafe code with memory-safe de novo implementations. Fortunately, you mostly don't have that dilemma; there are good options in Go and Rust. But a lot of energy goes into auditing the cryptography code in OpenSSL. Certainly, you might reasonably pick OpenSSL over some random high-level implementation nobody is auditing.
That's why I think it's worth calling this out.
Odds are, it's some dumb memory corruption thing. But we don't know yet. OpenSSL sev:hi tends to mean "dubiously exploitable crasher", and good crypto bugs in OpenSSL tend to be sev:med.