4 ms·

But what if we rewrite it all in Rust bugs become impossible! /s

unilynx 6y ago
Moving all ASN/X509 handling to Rust might be worth it though. That stuff is a minefield and has had plenty of memory-safety issues in the past.
- mroche 6y ago
  Genuine question as I'm not a Rust professional, but if one was able to maintain the C API and headers to produce a drop in replacement for the current openssl implementation, would rewriting it in Rust produce a safer variant? This would be based off using the #[no_mangle] extensively, I presume, probably with some amount of "unsafe" usage? At which point has the primary use case of Rust in this situation been lost?
  - bluejekyll 6y ago
    What you're probably looking for is this project, which is a C API (I think ABI compatible) wrapper around Rustls that can be a "drop-in" replacement for OpenSSL: https://mesalink.io/ https://mesalink.io/ (note: not commenting on if one should or should not use it, only mentioning it's existence)
bluejekyll 6y ago
You jest, but at least in this case looking at both of the changes, these bugs wouldn't have happened in Rust. Better options for standard data structures and initialization: https://github.com/openssl/openssl/commit/fb9fa6b51defd48157eeb207f52181f735d96148 https://github.com/openssl/openssl/commit/fb9fa6b51defd48157... Error handling: https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de897a74571e7024f0cf0d63b https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de8...
- tptacek 6y ago
  I don't think there's a strong argument for the second one in Rust. It's not an error handling bug as much as a simple logic bug; it's aggregating the results of multiple checks.
  - bluejekyll 6y ago
    Perhaps not a strong argument, but in idiomatic Rust (i.e. if you ran clippy on it and it passes checks) I'm fairly certain it would be less likely to happen. That said, of course you can end up with a similar bug in Rust, there are just nice ways the language encourages practices that would avoid it.
    - tptacek 6y ago
      I don't want to belabor this too much. Rust has a lot of exhaustive checking tools that other languages don't, so I don't want to claim that it would do nothing to reduce the likelihood of these kinds of mistakes. But if I go to my 3p directory and grep across all the Rust dependencies I've got, I can find plenty of code that has, like, `let mut checked = false` and that goes on to compute `checked`. That's what basically happened here. None of the individual checks were missed; they were just aggregated into a result improperly.
PoignardAzur 6y ago
You're joking, but the audit of rustls last year by Cure53 concluded with "We were unable to uncover any application-breaking security flaw" and "the team of auditors considered the general code quality to be exceptional". https://github.com/ctz/rustls/blob/master/audit/TLS-01-report.pdf https://github.com/ctz/rustls/blob/master/audit/TLS-01-repor...

Moving all ASN/X509 handling to Rust might be worth it though. That stuff is a minefield and has had plenty of memory-safety issues in the past.

mroche 6y ago
Genuine question as I'm not a Rust professional, but if one was able to maintain the C API and headers to produce a drop in replacement for the current openssl implementation, would rewriting it in Rust produce a safer variant? This would be based off using the #[no_mangle] extensively, I presume, probably with some amount of "unsafe" usage? At which point has the primary use case of Rust in this situation been lost?
- bluejekyll 6y ago
  What you're probably looking for is this project, which is a C API (I think ABI compatible) wrapper around Rustls that can be a "drop-in" replacement for OpenSSL: https://mesalink.io/ https://mesalink.io/ (note: not commenting on if one should or should not use it, only mentioning it's existence)

bluejekyll 6y ago

You jest, but at least in this case looking at both of the changes, these bugs wouldn't have happened in Rust. Better options for standard data structures and initialization: https://github.com/openssl/openssl/commit/fb9fa6b51defd48157eeb207f52181f735d96148 https://github.com/openssl/openssl/commit/fb9fa6b51defd48157... Error handling: https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de897a74571e7024f0cf0d63b https://github.com/openssl/openssl/commit/2a40b7bc7b94dd7de8...

tptacek 6y ago
I don't think there's a strong argument for the second one in Rust. It's not an error handling bug as much as a simple logic bug; it's aggregating the results of multiple checks.
- bluejekyll 6y ago
  Perhaps not a strong argument, but in idiomatic Rust (i.e. if you ran clippy on it and it passes checks) I'm fairly certain it would be less likely to happen. That said, of course you can end up with a similar bug in Rust, there are just nice ways the language encourages practices that would avoid it.
  - tptacek 6y ago
    I don't want to belabor this too much. Rust has a lot of exhaustive checking tools that other languages don't, so I don't want to claim that it would do nothing to reduce the likelihood of these kinds of mistakes. But if I go to my 3p directory and grep across all the Rust dependencies I've got, I can find plenty of code that has, like, `let mut checked = false` and that goes on to compute `checked`. That's what basically happened here. None of the individual checks were missed; they were just aggregated into a result improperly.

PoignardAzur 6y ago

You're joking, but the audit of rustls last year by Cure53 concluded with "We were unable to uncover any application-breaking security flaw" and "the team of auditors considered the general code quality to be exceptional". https://github.com/ctz/rustls/blob/master/audit/TLS-01-report.pdf https://github.com/ctz/rustls/blob/master/audit/TLS-01-repor...