11 ms·

I am not among the ones who would blindly say 'rewrite it in rust', but given what happened with log4j, I would much rather choose a safe implementation given t

by mfrw 5y ago

I am not among the ones who would blindly say 'rewrite it in rust', but given what happened with log4j, I would much rather choose a safe implementation given the memory safety provided by rust. This also does not mean rust might not have its fair share of bugs; IMHO the probability is a little less. Edit: I mentioned the log4j RCE as it was new & do not mean to imply that it would not have happened if we had a rust implementation. As the comments have mentioned, it would be the same in any language IMO

zamalek 5y ago
> IMHO the probability is a little less. Exactly, Rust simply eliminates a certain class of bugs. You can still make some really major mistakes in the absence of these bugs, e.g. "goto fail" could have easily been written in Rust.
- ordiel 5y ago
  Most certainly opening the door to a diffetent kind of bugs. This mentally of tying bugs to a language demonstrates a very poor understanding of the issues themselves, and if anything a large impacting bug demonstrates wide adoption of an individual piece, most probably choosen due to its stability or ease of use. Remember heartbleed?...
  - staticassertion 5y ago
    > Most certainly opening the door to a diffetent kind of bugs. No? There's no law of conservation of bug class or something, you can eliminate bug classes without introducing a new one. > This mentally of tying bugs to a language demonstrates a very poor understanding of the issues themselves, No it doesn't. > and if anything a large impacting bug demonstrates wide adoption of an individual piece, most probably choosen due to its stability or ease of use. I don't think this has held true historically, and log4j is a good example of this (though there are many others). > Remember heartbleed?... A weird point to bring up since heartbleed was an out of bounds memory read.
- vlmutolo 5y ago
  The "goto fail" bug isn't a great example; Rust actually does specifically guard against this by requiring curly braces around the body of "if". Here's an explanation of "goto fail", which includes a code snippet. https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... If C conditionals required explicit braces around the body, the second fail would have been redundant code instead of a security vulnerability. Additonally, Rust will warn you if you have "unreachable" code, such as all the code after the unconditional "goto fail". Though, I'm sure modern C compilers would also warn about this. All that said, Rust definitely does have plenty of bug classes left for people to trip over. Integer under/overflows come to mind (though they're just logic errors instead of undefined behavior).
  - tialaramex 5y ago
    In the same class as the integer over/underflows, Rust also doesn't warn for throwing away information when casting. So (my_value as u16) might be a completely safe transformation from an unsigned one byte my_value to a u16, but it might be throwing away the top 16-bits of a 32-bit value and Rust doesn't think that's worth any additional caution. Rust also hasn't boarded the "People can't remember precedence rules" train like some modern languages. It has fewer operators with unnecessary values, reducing some opportunities for mistakes like C's increment footgun, but it does still have precedence and so you can still forget the precedence rules which the compiler is going to apply to your code. But there are a lot of things Rust does catch, and there are even more things that aren't caught by Rust the language per se but are caught in idiomatic Rust because the language affords better ways to do things. Locking is an example, idiomatic Rust locking means you can't make the lock A but change B mistake seen so often in real bugs, because idiomatic use of Rust's type system would put the variable B inside the lock for B, if you didn't take the lock you don't have the variable to change it. https://doc.rust-lang.org/std/sync/struct.Mutex.html https://doc.rust-lang.org/std/sync/struct.Mutex.html
    - pjmlp 5y ago
      Another example would be bounds checking, yes it is much better than silenty corrupting memory, but dying with a panic might not be the best solution in some cases, specially if the application is controlling hardware. Not only Rust, this applies to all safe languages, just crashing also opens the door to exploits and denial attacks.
sorokod 5y ago
You misunderstand the recent RCE in log4j. It has nothing to do with memory safety and can be implemented in Rust without any difficulty.
- mfrw 5y ago
  I did not mean that the RCE of log4j is a memory safety issue, its just that, I would prefer to choose something where the probability of me having to wake up at the middle of the night and fix is less. Honestly, I would care less if it were memory safety or whatever, given I had to wake up at midnight :)
  - johnisgood 5y ago
    Just because it is written in Rust, it does not mean that you will have less bugs or whatever to fix. I could easily say that if it is written in Ada or Nim, then you will have way less bugs, as those languages are way easier to understand, and they are safe & fast & easy. Nim is just as easy as Python, and it is safe if you want it to.
    - mfrw 5y ago
      I completely agree. My choice of words was not not right.
    - moonchrome 5y ago
      >it does not mean that you will have less bugs or whatever to fix But it does since you eliminate an entire class of bugs, and a class that's generally the source of most exploits out there (eg. heartbleed comes to mind as a similar level of exploit but was a result of memory errors). JVM does the same with GC, and so do a lot of other languages, but when it comes to rewriting non-managed code Rust is a great choice over C in my book, I would feel better about introducing a Rust dependency over a C/C++ dependency just based on that. As for ADA and Nim, if it's some black box docker service then sure, otherwise if I have to include it in my build pipeline that's a hard pass.
      - 5y ago

by mfrw 5y ago

zamalek 5y ago

> IMHO the probability is a little less. Exactly, Rust simply eliminates a certain class of bugs. You can still make some really major mistakes in the absence of these bugs, e.g. "goto fail" could have easily been written in Rust.

ordiel 5y ago
Most certainly opening the door to a diffetent kind of bugs. This mentally of tying bugs to a language demonstrates a very poor understanding of the issues themselves, and if anything a large impacting bug demonstrates wide adoption of an individual piece, most probably choosen due to its stability or ease of use. Remember heartbleed?...
- staticassertion 5y ago
  > Most certainly opening the door to a diffetent kind of bugs. No? There's no law of conservation of bug class or something, you can eliminate bug classes without introducing a new one. > This mentally of tying bugs to a language demonstrates a very poor understanding of the issues themselves, No it doesn't. > and if anything a large impacting bug demonstrates wide adoption of an individual piece, most probably choosen due to its stability or ease of use. I don't think this has held true historically, and log4j is a good example of this (though there are many others). > Remember heartbleed?... A weird point to bring up since heartbleed was an out of bounds memory read.
vlmutolo 5y ago
The "goto fail" bug isn't a great example; Rust actually does specifically guard against this by requiring curly braces around the body of "if". Here's an explanation of "goto fail", which includes a code snippet. https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-goto-fail-apples-ssl-bug-explained-plus-an-unofficial-patch/ https://nakedsecurity.sophos.com/2014/02/24/anatomy-of-a-got... If C conditionals required explicit braces around the body, the second fail would have been redundant code instead of a security vulnerability. Additonally, Rust will warn you if you have "unreachable" code, such as all the code after the unconditional "goto fail". Though, I'm sure modern C compilers would also warn about this. All that said, Rust definitely does have plenty of bug classes left for people to trip over. Integer under/overflows come to mind (though they're just logic errors instead of undefined behavior).
- tialaramex 5y ago
  In the same class as the integer over/underflows, Rust also doesn't warn for throwing away information when casting. So (my_value as u16) might be a completely safe transformation from an unsigned one byte my_value to a u16, but it might be throwing away the top 16-bits of a 32-bit value and Rust doesn't think that's worth any additional caution. Rust also hasn't boarded the "People can't remember precedence rules" train like some modern languages. It has fewer operators with unnecessary values, reducing some opportunities for mistakes like C's increment footgun, but it does still have precedence and so you can still forget the precedence rules which the compiler is going to apply to your code. But there are a lot of things Rust does catch, and there are even more things that aren't caught by Rust the language per se but are caught in idiomatic Rust because the language affords better ways to do things. Locking is an example, idiomatic Rust locking means you can't make the lock A but change B mistake seen so often in real bugs, because idiomatic use of Rust's type system would put the variable B inside the lock for B, if you didn't take the lock you don't have the variable to change it. https://doc.rust-lang.org/std/sync/struct.Mutex.html https://doc.rust-lang.org/std/sync/struct.Mutex.html
  - pjmlp 5y ago
    Another example would be bounds checking, yes it is much better than silenty corrupting memory, but dying with a panic might not be the best solution in some cases, specially if the application is controlling hardware. Not only Rust, this applies to all safe languages, just crashing also opens the door to exploits and denial attacks.

sorokod 5y ago

You misunderstand the recent RCE in log4j. It has nothing to do with memory safety and can be implemented in Rust without any difficulty.

mfrw 5y ago
I did not mean that the RCE of log4j is a memory safety issue, its just that, I would prefer to choose something where the probability of me having to wake up at the middle of the night and fix is less. Honestly, I would care less if it were memory safety or whatever, given I had to wake up at midnight :)
- johnisgood 5y ago
  Just because it is written in Rust, it does not mean that you will have less bugs or whatever to fix. I could easily say that if it is written in Ada or Nim, then you will have way less bugs, as those languages are way easier to understand, and they are safe & fast & easy. Nim is just as easy as Python, and it is safe if you want it to.
  - mfrw 5y ago
    I completely agree. My choice of words was not not right.
  - moonchrome 5y ago
    >it does not mean that you will have less bugs or whatever to fix But it does since you eliminate an entire class of bugs, and a class that's generally the source of most exploits out there (eg. heartbleed comes to mind as a similar level of exploit but was a result of memory errors). JVM does the same with GC, and so do a lot of other languages, but when it comes to rewriting non-managed code Rust is a great choice over C in my book, I would feel better about introducing a Rust dependency over a C/C++ dependency just based on that. As for ADA and Nim, if it's some black box docker service then sure, otherwise if I have to include it in my build pipeline that's a hard pass.
    - 5y ago