8 ms·

We do take security pretty seriously with Hare. To quote our crypto module's introduction as an example: > Cryptography is a difficult, high-risk domain of pro

We do take security pretty seriously with Hare. To quote our crypto module's introduction as an example: > Cryptography is a difficult, high-risk domain of programming. The life and well-being of your users may depend on your ability to implement cryptographic applications with due care. Please carefully read all of the documentation, double-check your work, and seek second opinions and independent review of your code. Our documentation and API design aims to prevent easy mistakes from being made, but it is no substitute for a good background in applied cryptography. We have many safety features built into the language and the standard library is designed to be difficult to use incorrectly. I will address these concerns directly in a subsequent blog post covering the safety and security features of Hare. The main problem is that some programmers view anything less than what Rust provides as morally unjustified.

Gwypaas 4y ago
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
- 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".
mplewis 4y ago
When you say you take security pretty seriously, and mention the Hare crypto module, are you talking about the crypto module which silently falls back to storing secure data on the heap when Linux keyctl is not present on the platform? https://lwn.net/Articles/893327/ https://lwn.net/Articles/893327/
- ddevault 4y ago
  Yes. As I reiterated many times in that thread, having your data stored in the heap does not introduce any immediate vulnerabilities, and this behavior is thoroughly documented in the standard library. It is possible for two people who both take security seriously to come away with different take-aways. Once some CVEs are found in Hare you might have some fuel for your argument, but until then it's just speculation.
CJefferson 4y ago
I didn't mention Rust (beyond mentioning you discussed it). You seem very Rust obsessed.
- verdagon 4y ago
  Honestly, I don't blame him, after the onslaught he's been defending against in every other thread since Hare's launch. It's really embarrassing to see that side of the Rust community acting this way.

Gwypaas 4y ago

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
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".

mplewis 4y ago

When you say you take security pretty seriously, and mention the Hare crypto module, are you talking about the crypto module which silently falls back to storing secure data on the heap when Linux keyctl is not present on the platform? https://lwn.net/Articles/893327/ https://lwn.net/Articles/893327/

ddevault 4y ago
Yes. As I reiterated many times in that thread, having your data stored in the heap does not introduce any immediate vulnerabilities, and this behavior is thoroughly documented in the standard library. It is possible for two people who both take security seriously to come away with different take-aways. Once some CVEs are found in Hare you might have some fuel for your argument, but until then it's just speculation.

CJefferson 4y ago

I didn't mention Rust (beyond mentioning you discussed it). You seem very Rust obsessed.

verdagon 4y ago
Honestly, I don't blame him, after the onslaught he's been defending against in every other thread since Hare's launch. It's really embarrassing to see that side of the Rust community acting this way.