Hacker News Reader

Hacker News

Comment by LeonM | Hacker News Reader

Parent Full thread

LeonM

Looking at the actual commit for this issue:

https://github.com/openssl/openssl/commit/f960d81215ebf3f65e...

I highly doubt that rust would have prevented this.

Rust is not a silver bullet that solves all bugs.

View on HN

Clearly Rust can't solve all bugs, but I bet it would have prevented this one.

GENERAL_NAME[1] is a struct containing a type tag "enum" and a union of the data (d) for each type. If I'm reading it right the bug here is reading the union as 'other' when the tag says its `GEN_EDIPARTY`.

In rust this would just be a fat enum where the variants of the enum would actually contain the data that this has in the union. Then the Rust compiler would only allow you to read the data as the type it's stored as.

[1] https://github.com/openssl/openssl/blob/13a574d8bb2523181f81...

A segfault? Yes, rust would've probably prevent it.

When determining whether a certificate has been revoked, is an Error<T> really more desirable than a segfault? Would you even expect a "is certificate revoked" function to return an Error<T>?

> is an Error<T> really more desirable than a segfault?

It's only by happy coincidence that it manifests cleanly as a segfault. In the C language, dereferencing NULL causes undefined behaviour, so all manner of peculiar things can happen. This isn't just theoretical nit-picking, it can happen with real code:

• Raymond Chen's Undefined behavior can result in time travel (among other things, but time travel is the funkiest), https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

• John Regehr's A Guide to Undefined Behavior in C and C++, Part 1, https://blog.regehr.org/archives/213 (ctrl-f for A Fun Case Analysis)

The code in question [1] does indeed return Result<(), Error>. This makes sense - more than one thing can go wrong during the verification, and the details can be important in some situations.

[1]: https://docs.rs/webpki/0.21.4/webpki/struct.EndEntityCert.ht...

In Rust, the signature of the function would be along the lines of `-> Result<whatever, Error>` and you'd have no choice but to handle the Error case of the Result or to panic. Either way, not a segfault.

> Would you even expect a "is certificate revoked" function to return an Error<T>?

Depends on how it's doing the check. If it has to fetch the CRL from the CRLdp or do OCSP with the OSCP AIA, like CAPI does, then it definitely has to have an error for when certificate revocation status is not available.

Honestly, even if I provide the cert & CRL, it should probably be able to throw an error if either one has invalid ASN.1 encoding or such.

You have no choice in rust. It wont compile unless you handle all error conditions.

You get Result< Data T, Error>. And you have to handle Error condition (usually kick it up stack, but it has to be handled somewhere) for it to compile.

What rust wouldn't prevent you from is forgetting to check for revocation, or doing it wrong.

You do not handle errors by randomly segfaulting.

Rust solves exactly this kind of bug though.

Reply on news.ycombinator.com