While this is a true statement, it doesn't feel accurate. Rust's type system offers a significant number of features over that of C beyond just memory safety. These come in the form of safe unions (with Rust enums), Generics with ZeroSizedTypes for ensuring states of computation happen in the proper order, safe destructuring of values such that the wrong field isn't referenced.

Point being, a Rust library that incorporates these type of safety measures can help significantly reduce programming errors beyond just memory safety issues.

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.

Not looking for an argument, just trying to incorporate some more perspective.

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.

Memory errors and the sort of logic errors you described are one source of program errors, but I think the more devious ones are much higher level. There's a general taboo surrounding rolling your own crypto for a reason -- there are too many high level footguns that have nothing to do with raw program logic that can make a crypto system insecure or vulnerable to some kind of exploit, not necessarily relating to the code at all! Problems in randomness, distribution, other things beyond my pay grade.

Rust being higher level will prevent errors, yes, but crypto is hard on a whole other level. It's worth "waiting and seeing" what sort of vuln this is before jumping all in on the rust train this time ;-)

No argument from me that you can easily go wrong in any language, but I would argue that Rust has features other than memory safety that can also assist in building more reliable/secure software.

Such as?

The Rust type system can define parts of the state machine that can help guarantee certain states are true at compile time.

This is very helpful for not using cryptography libraries incorrectly, or not accidentally using the wrong data at different points of implementing functions.

Generally more applicable to higher level use cases, the ring[1] library is a great example of how the algorithms (same impls as OpenSSL) are exposed to end users.

[1]: https://github.com/briansmith/ring

I like Ring but I don't think there's a lot of evidence that Rust's type system has effectively prevented cryptography errors, either in protocol state machines or in primitive implementations.

The challenge in avoiding cryptography mistakes is that you have to understand the errors before you can avoid them. Short of formal analysis with provers, I don't think there's a level of programming rigor that gets you away from most (maybe any?) of the last 10-15 years of (say) {TLS,JWT} bugs.

I look forward to discussing that on the 25th when we have more information.

Evidence of this nature will always be difficult, though, since it’s very difficult to prove a negative. We can only prove that some specific issue hasn’t yet occurred.

Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).

Any respectable C compiler does this.

What C compiler has pattern matching and ADTs?

Every C compiler these days will warn about unchecked enums in switch statements. This is, effectively, what the comment was saying.

Pattern matching has nothing to do with security or program safety.

Like the one OpenSSL is being compiled with?

From what I remember, you can't write a secure cryptography library in pure Rust because it has no guarantees that would stop timing-based vulnerabilities.

Neither does C. Timing is not considered "observable behavior" in the C standard, so compilers don't have to preserve it.

It looks like at least libsodium implements constant-time array comparison in C.

https://github.com/jedisct1/libsodium/blob/ae4add868124a32d4...

Edit: I'm not disagreeing that C compilers are free to optimize stuff like this out; this comment is for people who (like me) thought that serious projects always used assembly for constant time operations.

There's nothing that guarantees that's constant-time. It's just written in a way that's likely to be constant-time, and observed to be constant-time with current compilers, but there's no reason why a specification-compliant compiler couldn't make it variable-time tomorrow.

You can do exactly the same in Rust. Rust isn't any help there, but it doesn't obstruct you either.

We've had code in OpenSSL written in C that was constant time until a newer version of both gcc and clang recognized (mask & a | ~mask & b) as a conditional assign and could do things like turn it into a branch.

Edit: It can turn "b = foo(); c = (mask & a | ~mask & b)" into "if (mask) c = a; else c = foo();"

And indeed the XOR method is also how it's implemented in Rust.

https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#226-244 - the impl for [u8], where the per-element ct_eq is

https://docs.rs/subtle/2.4.0/src/subtle/lib.rs.html#259-272 - the impl for u8

Which is prime example as to how C does not consider timing to be observable behavior. What the code does is that it tries to specify the operation in sufficiently complex way that makes compiler give up on any optimizations.

Note how this problem of "sufficient complexity" is an asymmetric problem between code author and compiler. A rather simple transformation implemented by the author to make the code constant-time may require NP-hard effort for the compiler to undo.

(but then the compiler may still do other unrelated transformations that end up making the code non-constant time again)