5 ms·

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 buil

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.

wglb 6y ago
Such as?
- dochtman 6y ago
  Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
  - junon 6y ago
    Any respectable C compiler does this.
    - sshine 6y ago
      Like the one OpenSSL is being compiled with?
    - SubjectToChange 6y ago
      What C compiler has pattern matching and ADTs?
      - junon 6y ago
        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.
- bluejekyll 6y ago
  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 https://github.com/briansmith/ring
  - tptacek 6y ago
    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.
    - bluejekyll 6y ago
      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.

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.

wglb 6y ago

Such as?

dochtman 6y ago
Match statement exhaustiveness checking is one example, especially combined with the pervasiveness of enums (instead of constants).
- junon 6y ago
  Any respectable C compiler does this.
  - sshine 6y ago
    Like the one OpenSSL is being compiled with?
  - SubjectToChange 6y ago
    What C compiler has pattern matching and ADTs?
    - junon 6y ago
      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.
bluejekyll 6y ago
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 https://github.com/briansmith/ring
- tptacek 6y ago
  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.
  - bluejekyll 6y ago
    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.