4 ms·

Because rust inherently treats humans as fallible to a large extent. Which all of us are. That introduction is simply an appeal to "I can write safe correct C.

Because rust inherently treats humans as fallible to a large extent. Which all of us are. That introduction is simply an appeal to "I can write safe correct C." with more words. Which obviously is not true.

ddevault 4y ago
I can assure you that Hare takes security more seriously than assuming the programmer is smart enough to do it right. I don't appreciate shallow takes which make unsympathetic judgements on the language which are not based in any understanding of how Hare actually works, and I've heard nothing but such takes for a week.
- Filligree 4y ago
  How does Hare prevent use-after-free, then? I'd welcome an explanation.
  - ddevault 4y ago
    Hare does not prevent use-after-free, but it does prevent many other kinds of bugs which are common in C. I will go into greater detail in another blog post.
- staticassertion 4y ago
arghwhat 4y ago
> Because rust inherently treats humans as fallible to a large extent. Which all of us are. No it doesn't. It has a bypassable compile-time verified lifetime system, not an infallible programming guarantee. It leaves it entirely up to the developers to write correct and safe applications and libraries, and merely provides (powerful) tools to help. (I realize this context was in avoiding common security bugs which are usually less likely in memory-safe languages, but it's important to not overstate the benefits.)
- ddevault 4y ago
  http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust "use-after-free", "data race", "memory corruption", "out-of-bounds write", "read from uninitialized memory", "execute arbitrary code"...
  - marcosdumay 4y ago
    Wait, that's all? On the entire Rust ecosystem those are the only ones found? Everybody already knows Rust has unsafe blocks and C FFI. It is not invulnerable to those problems, Rust just makes it very clear where those problems may appear, and if you are smart, you will place most of your code outside of those regions. Looks like Rust is much safer on practice than what I expected.
    - arghwhat 4y ago
      Note that unsafe does not contain anything. The problem propagates to the unsuspecting caller of claimed safe code. Ending up compromised by a problem in tokio, Pin semantics, actix or all the necessary ffi bindings is no different than, say, a C program being compromised by a vulnerability in OpenSSL or libcurl. A very significant number of memory issues in C stemmed from issues in such single high-profile dependency, so one should not undermine the threat of a bit of unsafe code in the corner of a library.
      - pierrebai 4y ago
        Not being perfect does not translate to not being better. Being safe by default and having compiler-enforced safety as a top design choice is great. Rust is better. It's very much human nature to trace the line in the sand juuuuuust right behind one's heels though, depicting everyone behind as bad and everyone ahead as zealots.
        arghwhat 4y ago
        I did not say rust was not better. I said the statement was false, based on a misunderstanding of both the benefits of Rust and the problems of C many if which Rust is not immune to. Rust is definitely better, hands down, but insisting on thinking code that interacts with unsafe blocks can be "safe by default" is a dangerously wrong mindset which also makes unsafe blocks proliferate without the necessary caution as the problem seem "contained". Anyone remember the actix unsafe saga? But even though a program with unsafe blocks (read: all rust programs) are by definition not memory safe - calling a language memory safe on current platforms can to some extend even be considered a misnomer - the assistance provided by rust by default certainly helps make such programs much safer.
jupp0r 4y ago
Rust has compile time checks that avoid one category of bugs out of many. It’s “safe” in a very narrow sense.
- cyber_kinetist 4y ago
  And that category of bugs (memory safety) is only avoidable if the unsafe code itself doesn't have undefined behavior (which responsibility is left to the programmer rather than the compiler). If unsafe code is compromised then it's still game over (hence the recent development of various tools/methods like Stacked Borrows in MIRI that checks potential errors outside the borrow checker, as well as various guidelines for developers to write safer unsafe code) Safe Rust cannot ever cause undefined behavior, but Unsafe Rust can. The ultimate merit of Rust is that when you suspect any undefined behavior you only need to check the unsafe part, which is a much smaller percentage of your codebase (as opposed to C/C++ where you need to check the entirety of your code)
  - uecker 4y ago
    It is not enough to check your unsafe code for UB, you also need to make sure it does not violate the invariants Rust relies on to prove the safe code safe.
    - cyber_kinetist 4y ago
      ...which I consider as one of the bullet points in the list when checking UB in unsafe code.
    - staticassertion 4y ago
      ???? Whatever that means lol You mean the borrow checker? People are working on formally proving that, and have already done so for large subsets of the language.
      - ColonelPhantom 4y ago
        They mean that in unsafe code, you have to adhere to some rules to prevent safe code from becoming unsafe. In other words, incorrect code in "unsafe Rust" can cause safety issues that only appear when you use it in a certain way from "safe Rust".

ddevault 4y ago

I can assure you that Hare takes security more seriously than assuming the programmer is smart enough to do it right. I don't appreciate shallow takes which make unsympathetic judgements on the language which are not based in any understanding of how Hare actually works, and I've heard nothing but such takes for a week.

Filligree 4y ago
How does Hare prevent use-after-free, then? I'd welcome an explanation.
- ddevault 4y ago
  Hare does not prevent use-after-free, but it does prevent many other kinds of bugs which are common in C. I will go into greater detail in another blog post.
staticassertion 4y ago

arghwhat 4y ago

> Because rust inherently treats humans as fallible to a large extent. Which all of us are. No it doesn't. It has a bypassable compile-time verified lifetime system, not an infallible programming guarantee. It leaves it entirely up to the developers to write correct and safe applications and libraries, and merely provides (powerful) tools to help. (I realize this context was in avoiding common security bugs which are usually less likely in memory-safe languages, but it's important to not overstate the benefits.)

ddevault 4y ago
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust "use-after-free", "data race", "memory corruption", "out-of-bounds write", "read from uninitialized memory", "execute arbitrary code"...
- marcosdumay 4y ago
  Wait, that's all? On the entire Rust ecosystem those are the only ones found? Everybody already knows Rust has unsafe blocks and C FFI. It is not invulnerable to those problems, Rust just makes it very clear where those problems may appear, and if you are smart, you will place most of your code outside of those regions. Looks like Rust is much safer on practice than what I expected.
  - arghwhat 4y ago
    Note that unsafe does not contain anything. The problem propagates to the unsuspecting caller of claimed safe code. Ending up compromised by a problem in tokio, Pin semantics, actix or all the necessary ffi bindings is no different than, say, a C program being compromised by a vulnerability in OpenSSL or libcurl. A very significant number of memory issues in C stemmed from issues in such single high-profile dependency, so one should not undermine the threat of a bit of unsafe code in the corner of a library.
    - pierrebai 4y ago
      Not being perfect does not translate to not being better. Being safe by default and having compiler-enforced safety as a top design choice is great. Rust is better. It's very much human nature to trace the line in the sand juuuuuust right behind one's heels though, depicting everyone behind as bad and everyone ahead as zealots.
      - arghwhat 4y ago
        I did not say rust was not better. I said the statement was false, based on a misunderstanding of both the benefits of Rust and the problems of C many if which Rust is not immune to. Rust is definitely better, hands down, but insisting on thinking code that interacts with unsafe blocks can be "safe by default" is a dangerously wrong mindset which also makes unsafe blocks proliferate without the necessary caution as the problem seem "contained". Anyone remember the actix unsafe saga? But even though a program with unsafe blocks (read: all rust programs) are by definition not memory safe - calling a language memory safe on current platforms can to some extend even be considered a misnomer - the assistance provided by rust by default certainly helps make such programs much safer.

jupp0r 4y ago

Rust has compile time checks that avoid one category of bugs out of many. It’s “safe” in a very narrow sense.

cyber_kinetist 4y ago
And that category of bugs (memory safety) is only avoidable if the unsafe code itself doesn't have undefined behavior (which responsibility is left to the programmer rather than the compiler). If unsafe code is compromised then it's still game over (hence the recent development of various tools/methods like Stacked Borrows in MIRI that checks potential errors outside the borrow checker, as well as various guidelines for developers to write safer unsafe code) Safe Rust cannot ever cause undefined behavior, but Unsafe Rust can. The ultimate merit of Rust is that when you suspect any undefined behavior you only need to check the unsafe part, which is a much smaller percentage of your codebase (as opposed to C/C++ where you need to check the entirety of your code)
- uecker 4y ago
  It is not enough to check your unsafe code for UB, you also need to make sure it does not violate the invariants Rust relies on to prove the safe code safe.
  - cyber_kinetist 4y ago
    ...which I consider as one of the bullet points in the list when checking UB in unsafe code.
  - staticassertion 4y ago
    ???? Whatever that means lol You mean the borrow checker? People are working on formally proving that, and have already done so for large subsets of the language.
    - ColonelPhantom 4y ago
      They mean that in unsafe code, you have to adhere to some rules to prevent safe code from becoming unsafe. In other words, incorrect code in "unsafe Rust" can cause safety issues that only appear when you use it in a certain way from "safe Rust".