3 ms·

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

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.
  - ptx 3y ago
    Isn't that the idea that unsafe code can do unsafe things internally while exposing a safe interface? So in your example the bug would be in the unsafe code, which shouldn't have allowed the unsafety to leak into the safe code.
    - BobbyTables2 3y ago
      Yes, but by that same logic, safe programs can also be written C. However, I do believe Rust gets a whole lot of things right. I sincerely hope that unnecessary use of unsafe code is avoided.
- arccy 3y ago
  you don't need unsafe to sneak in a cryptominer
  - jsheard 3y ago
    Hence why I said it gives you an idea of exposure to memory safety issues, not that grep unsafe is a substitute for a full audit. Besides, time not spent having to pore over every line of code looking for subtle memory safety bugs is time you can spend looking for bundled cryptominers instead.
- robertlagrant 3y ago
  > you can get an idea of a crates attack surface at a glance just by grepping for it I hope that the code that streams your data out to an endpoint isn't memory safe, so you easily find it!
steveklabnik 3y ago
https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies is an interesting exploration of these dynamics.
kstrauser 3y ago
> an obtological error I don't know if that was a deliberate portmanteau of obtuse+ontological, or if it was a happy typo, but I'm stealing it.
- estebank 3y ago
  It was typo ^_^'
arccy 3y ago
teams might split their own stuff into crates, but rust has still managed to adopt to npm culture of pulling in lots of small dependencies for trivial things, opening them up to different sorts of supply chain attacks.
cperciva 3y ago
> the amount of code and level of risk taken would be exactly the same. The amount of code might be the same, but that doesn't guarantee that the level of risk is the same. A lot of bugs are introduced at interfaces -- the provider of an API makes a subtle change without realizing how it affects some of the API consumers -- and that's inherently more likely to occur if the two sides of the API are developed separately. In the FreeBSD world we've found that it's incredibly useful to develop the kernel and libc and system binaries together; all sorts of problems Linux trips over simply never happen in FreeBSD.
- josephg 3y ago
  This risk is much worse in C or C++ than rust because of the borrow checker. I’ve certainly seen some crimes against performance at the boundary between libraries, but I don’t think I’ve seen any subtle interface bugs.
- estebank 3y ago
  A really common thing in the Rust ecosystem is to write APIs that are impossible or at least hard to misuse. That cultural aspect plus the ownership system does help reduce those kind of problems. I've seen crates where there are "mistakes" in the API, lending a mutable borrow instead of returning an owned value, for example, that make them less useful than they could be otherwise, but I've seen fewer cases of bug prone APIs.

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.
- ptx 3y ago
  Isn't that the idea that unsafe code can do unsafe things internally while exposing a safe interface? So in your example the bug would be in the unsafe code, which shouldn't have allowed the unsafety to leak into the safe code.
  - BobbyTables2 3y ago
    Yes, but by that same logic, safe programs can also be written C. However, I do believe Rust gets a whole lot of things right. I sincerely hope that unnecessary use of unsafe code is avoided.
arccy 3y ago
you don't need unsafe to sneak in a cryptominer
- jsheard 3y ago
  Hence why I said it gives you an idea of exposure to memory safety issues, not that grep unsafe is a substitute for a full audit. Besides, time not spent having to pore over every line of code looking for subtle memory safety bugs is time you can spend looking for bundled cryptominers instead.
robertlagrant 3y ago
> you can get an idea of a crates attack surface at a glance just by grepping for it I hope that the code that streams your data out to an endpoint isn't memory safe, so you easily find it!

steveklabnik 3y ago

https://wiki.alopex.li/LetsBeRealAboutDependencies https://wiki.alopex.li/LetsBeRealAboutDependencies is an interesting exploration of these dynamics.

kstrauser 3y ago

> an obtological error I don't know if that was a deliberate portmanteau of obtuse+ontological, or if it was a happy typo, but I'm stealing it.

estebank 3y ago
It was typo ^_^'

arccy 3y ago

teams might split their own stuff into crates, but rust has still managed to adopt to npm culture of pulling in lots of small dependencies for trivial things, opening them up to different sorts of supply chain attacks.

cperciva 3y ago

> the amount of code and level of risk taken would be exactly the same. The amount of code might be the same, but that doesn't guarantee that the level of risk is the same. A lot of bugs are introduced at interfaces -- the provider of an API makes a subtle change without realizing how it affects some of the API consumers -- and that's inherently more likely to occur if the two sides of the API are developed separately. In the FreeBSD world we've found that it's incredibly useful to develop the kernel and libc and system binaries together; all sorts of problems Linux trips over simply never happen in FreeBSD.

josephg 3y ago
This risk is much worse in C or C++ than rust because of the borrow checker. I’ve certainly seen some crimes against performance at the boundary between libraries, but I don’t think I’ve seen any subtle interface bugs.
estebank 3y ago
A really common thing in the Rust ecosystem is to write APIs that are impossible or at least hard to misuse. That cultural aspect plus the ownership system does help reduce those kind of problems. I've seen crates where there are "mistakes" in the API, lending a mutable borrow instead of returning an owned value, for example, that make them less useful than they could be otherwise, but I've seen fewer cases of bug prone APIs.