5 ms·

Using rustls[1] instead of openssl has worked well for me so far. [1] https://github.com/ctz/rustls https://github.com/ctz/rustls

• LeonM 6y ago
  Looking at the actual commit for this issue: https://github.com/openssl/openssl/commit/f960d81215ebf3f65e03d4d5d857fb9b666d6920 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.
  • bfrog 6y ago
    A segfault? Yes, rust would've probably prevent it.
    • TiltMeSenpai 6y ago
      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>?
      • Natsu 6y ago
        > 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.
      • scolby33 6y ago
        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.
      • NieDzejkob 6y ago
        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.html https://docs.rs/webpki/0.21.4/webpki/struct.EndEntityCert.ht...
      • MaxBarraclough 6y ago
        > 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=633 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 https://blog.regehr.org/archives/213 (ctrl-f for A Fun Case Analysis)
      • 29athrowaway 6y ago
        You do not handle errors by randomly segfaulting.
      • unionpivo 6y ago
        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.
  • azdle 6y ago
    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/13a574d8bb2523181f8150de49bc041c9841f59d/include/openssl/x509v3.h.in#L137-L167 https://github.com/openssl/openssl/blob/13a574d8bb2523181f81...
  • gameswithgo 6y ago
    Rust solves exactly this kind of bug though.