3 ms·

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 c

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!

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!