6 ms·

This is what I keep saying about Rust. Maybe you have 70% fewer vulnerabilities per line of code than C++ if really 70% of (old) C++ vulnerabilities are memory

This is what I keep saying about Rust. Maybe you have 70% fewer vulnerabilities per line of code than C++ if really 70% of (old) C++ vulnerabilities are memory related. But if you then pull in hundreds of packages in Rust and have 10x as many lines of code... 30% of 100k lines is more in total than 100% of 10k lines of code.

tcoff91 3y ago
memory related vulnerabilities tend to be the worst kind though, like RCEs and stuff. Remote code execution is so much worse than many other types of vulnerabilities like DOS. How many RCEs have there been in rust programs compared with C++? I bet C++ has far more than 70% more RCE frequency than rust.
- bsdpufferfish 3y ago
  Only for software directly connected to the internet. Unix process separation is a thing too.
- lionkor 3y ago
  the worst kind? probably not. The worst kind is the vulerability that is a logic error, which no language catches for you, which can leave unskilled attackers accidentally breavhing your whole system. RCE takes effort usually, exploiting a logic error not so much. For example, rust happily lets you access a database before checking that the user's auth token is valid - absolutely nothing prevents you from that.
estebank 3y ago
Counting crates and comparing that with number of C++ libraries is making an obtological error. In Rust, a single team usually splits their project in multiple crates. Something like QT would be hundreds of crates on its own if it were written in Rust, but the amount of code and level of risk taken would be exactly the same.
- jsheard 3y ago
  Plus many crates have zero unsafe code, so they're not much of a liability at least in terms of the common memory safety problems. The nice thing about unsafe code having to be declared is you can get an idea of a crates attack surface at a glance just by grepping for it - if only evaluating C/C++ libraries were so easy.
  - PhilipRoman 3y ago
    >you can get an idea of a crates attack surface at a glance just by grepping for it please don't... I understand your point but there are hundreds of vulnerabilities introduced every day in memory-safe languages that have nothing to do with rust's concept of "unsafe".
  - PH95VuimJjqBqy 3y ago
    no, absolutely not, and I have no idea where this misapprehension came from. the root cause of a problem in unsafe could can absolutely be from safe code because the safe code can set state in a way that causes problems. One can easily see this if you consider safe code that sets an index and then calls into unsafe code but the index is out of range. The root cause is absolutely in the safe code.
    - jsheard 3y ago
      There has to be unsafe code for that to happen though, if you consume a crate which doesn't touch unsafe at all then it's only going to happen if you write the sloppy unsafe code which makes assumptions that don't actually hold. If you blindly pass indices from code you didn't write and haven't audited into Slice::get_unchecked() then that's on you, if you're not willing to do your due diligence then stick to the bounds checked version. That's what it's there for.
      - PH95VuimJjqBqy 3y ago
        unsafe code should be sitting in a module protected by safe code. Which implies safe code can be the root cause of unsafety. People have got to stop believing that safe code in rust is automatically not the root cause of problems. It's a misapprehension.
Ygg2 3y ago
> But if you then pull in hundreds of packages in Rust and have 10x as many lines of code... No one is forcing you to use the libraries. Just write your own software stack yourself. But big problem is vulnerablilities. Is it better to fix hundred libs by fixing a bug in one shared lib or is it better to fix hundred libs one by one?
- whstl 3y ago
  False dichotomy. What is actually better is to have code that is properly auditable for end-users, or even to not introduce the risk for those vulnerabilities in the first place. Things like Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people, and were hidden inside bloated code. The same thing is happening now with package supply chain.
  - Ygg2 3y ago
    It's not a false dichotomy. You either put your vulnerabilities in a few baskets, or you spread (and multiply) them in many more baskets. Neither is intrinsically better. Why multiply? If everyone rolls their own libs, you can expect different library makers to repeat similar mistakes (stuff like not sanitizing input, forgetting to cap anything that generates output from outside sources, etc.). > Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people Minority of people need SSL and logging?!? Most applications need logging, and most of today's applications need the Internet to function. Could have they been omitted when possible? Perhaps, but you're not making a persuasive argument.
    - whstl 3y ago
      I never said people should roll their own. I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. I didn’t make a suggestion, but micro-packages aren’t silver bullets. Deep transitive dependencies are problematic for their lack of visibility, and often a signal of bloat. > Minority of people need SSL and logging?! Heartbleed and Log4Shell weren’t caused by the core SSL or logging code of those libraries, they were caused by code in niche features (heartbeat extension and SAMBA) that should have been plugins (or at least deactivatable by flags). that would massively decrease their impact. Both Heartbleed and Log4Shell were caused by feature bloat and lack of auditability.
IshKebab 3y ago
Do you have any evidence that Rust programs actually run 10x as much code as C++ programs? That seems very unlikely. Most translations from C++ to Rust or vice versa that I've seen are within like 30% of each other. The fact that Rust makes it easy to pull in a large number of small dependencies instead of a few enormous dependencies is irrelevant. You aren't using any more code. For example are you counting Rusts `regex` crate as a dependency? Well that's just in the standard library for C++. Does Boost count as a single dependency in C++? Because that would be like 30 separate crates in Rust.
- jurschreuder 3y ago
  Just to pick out some examples, rust-analyzer is 28M against clangd which is only 291K; ripgrep is 4.7M against GNU grep which is only 211K (binaries have already been strip-ed in both cases).

tcoff91 3y ago

memory related vulnerabilities tend to be the worst kind though, like RCEs and stuff. Remote code execution is so much worse than many other types of vulnerabilities like DOS. How many RCEs have there been in rust programs compared with C++? I bet C++ has far more than 70% more RCE frequency than rust.

bsdpufferfish 3y ago
Only for software directly connected to the internet. Unix process separation is a thing too.
lionkor 3y ago
the worst kind? probably not. The worst kind is the vulerability that is a logic error, which no language catches for you, which can leave unskilled attackers accidentally breavhing your whole system. RCE takes effort usually, exploiting a logic error not so much. For example, rust happily lets you access a database before checking that the user's auth token is valid - absolutely nothing prevents you from that.

estebank 3y ago

Counting crates and comparing that with number of C++ libraries is making an obtological error. In Rust, a single team usually splits their project in multiple crates. Something like QT would be hundreds of crates on its own if it were written in Rust, but the amount of code and level of risk taken would be exactly the same.

jsheard 3y ago
Plus many crates have zero unsafe code, so they're not much of a liability at least in terms of the common memory safety problems. The nice thing about unsafe code having to be declared is you can get an idea of a crates attack surface at a glance just by grepping for it - if only evaluating C/C++ libraries were so easy.
- PhilipRoman 3y ago
  >you can get an idea of a crates attack surface at a glance just by grepping for it please don't... I understand your point but there are hundreds of vulnerabilities introduced every day in memory-safe languages that have nothing to do with rust's concept of "unsafe".
- PH95VuimJjqBqy 3y ago
  no, absolutely not, and I have no idea where this misapprehension came from. the root cause of a problem in unsafe could can absolutely be from safe code because the safe code can set state in a way that causes problems. One can easily see this if you consider safe code that sets an index and then calls into unsafe code but the index is out of range. The root cause is absolutely in the safe code.
  - jsheard 3y ago
    There has to be unsafe code for that to happen though, if you consume a crate which doesn't touch unsafe at all then it's only going to happen if you write the sloppy unsafe code which makes assumptions that don't actually hold. If you blindly pass indices from code you didn't write and haven't audited into Slice::get_unchecked() then that's on you, if you're not willing to do your due diligence then stick to the bounds checked version. That's what it's there for.
    - PH95VuimJjqBqy 3y ago
      unsafe code should be sitting in a module protected by safe code. Which implies safe code can be the root cause of unsafety. People have got to stop believing that safe code in rust is automatically not the root cause of problems. It's a misapprehension.

Ygg2 3y ago

> But if you then pull in hundreds of packages in Rust and have 10x as many lines of code... No one is forcing you to use the libraries. Just write your own software stack yourself. But big problem is vulnerablilities. Is it better to fix hundred libs by fixing a bug in one shared lib or is it better to fix hundred libs one by one?

whstl 3y ago
False dichotomy. What is actually better is to have code that is properly auditable for end-users, or even to not introduce the risk for those vulnerabilities in the first place. Things like Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people, and were hidden inside bloated code. The same thing is happening now with package supply chain.
- Ygg2 3y ago
  It's not a false dichotomy. You either put your vulnerabilities in a few baskets, or you spread (and multiply) them in many more baskets. Neither is intrinsically better. Why multiply? If everyone rolls their own libs, you can expect different library makers to repeat similar mistakes (stuff like not sanitizing input, forgetting to cap anything that generates output from outside sources, etc.). > Heartbleed and Log4Shell were serious vulnerabilities that were useful only for a minority of people Minority of people need SSL and logging?!? Most applications need logging, and most of today's applications need the Internet to function. Could have they been omitted when possible? Perhaps, but you're not making a persuasive argument.
  - whstl 3y ago
    I never said people should roll their own. I said code should be auditable for end users. Hundreds (or thousands) of packages isn’t auditable. I didn’t make a suggestion, but micro-packages aren’t silver bullets. Deep transitive dependencies are problematic for their lack of visibility, and often a signal of bloat. > Minority of people need SSL and logging?! Heartbleed and Log4Shell weren’t caused by the core SSL or logging code of those libraries, they were caused by code in niche features (heartbeat extension and SAMBA) that should have been plugins (or at least deactivatable by flags). that would massively decrease their impact. Both Heartbleed and Log4Shell were caused by feature bloat and lack of auditability.

IshKebab 3y ago

Do you have any evidence that Rust programs actually run 10x as much code as C++ programs? That seems very unlikely. Most translations from C++ to Rust or vice versa that I've seen are within like 30% of each other. The fact that Rust makes it easy to pull in a large number of small dependencies instead of a few enormous dependencies is irrelevant. You aren't using any more code. For example are you counting Rusts `regex` crate as a dependency? Well that's just in the standard library for C++. Does Boost count as a single dependency in C++? Because that would be like 30 separate crates in Rust.

jurschreuder 3y ago
Just to pick out some examples, rust-analyzer is 28M against clangd which is only 291K; ripgrep is 4.7M against GNU grep which is only 211K (binaries have already been strip-ed in both cases).