8 ms·

Hare has significantly more safety and security features than C. Bounds-checked slices, no uninitialized data, mandatory error handling, nullable pointer types,

Hare has significantly more safety and security features than C. Bounds-checked slices, no uninitialized data, mandatory error handling, nullable pointer types, and others still. What it lacks that Rust users object to is a borrow checker.

CJefferson 4y ago
You don't need a borrow checker -- there are many ways to avoid use-after-free bugs. They don't in Java, or Haskell, or Python, to name 3 languages I work in sometimes. However, I really do think for a new "systems language" nowadays, you do want to look at how major security holes occur in practice, and have a good story on how users should avoid them.
- ddevault 4y ago
  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"...
  - 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.
- mikepurvis 4y ago
  > Java, or Haskell, or Python These are all GC'd languages that run bytecode on an abstract virtual machine. They avoid use-after-free by just not-freeing, if necessary at the cost of leaking unbounded amounts of memory. This doesn't invalidate the point that borrowing isn't the only way to solve this problem, but there are definitely classes of these bugs for which Rust's borrow checker is the only known production-ready solution that still has manual, deterministic memory management.
  - 4ad 4y ago
    Your point about GC stands, but I will note that Haskell is a compiled language.
    - eatonphil 4y ago
      And Go and native-image (GraalVM Java compiler) and Poly/ML (on x86) and MLton and OCaml (on x86) and Chicken Scheme and SBCL (and ECL).
throwaway82652 4y ago
You should be implementing a borrow checker or something like it. It's irresponsible not to do that. I'm serious about this. We know how to totally stop most use-after-free bugs during static analysis now, this is a tool that can be implemented in any language, so people should just do it. If you ask me the status quo moved a long time ago. This has nothing to do with Rust. Also I was wrong before and you were out of line. Matthew wasn't trolling, he never said you should be held criminally liable. You just made that criminal part up for no reason. Anyone should be held socially liable and shamed if their project has bad security and they refuse to fix it after they knew about it. I think you would even agree with that.

CJefferson 4y ago

You don't need a borrow checker -- there are many ways to avoid use-after-free bugs. They don't in Java, or Haskell, or Python, to name 3 languages I work in sometimes. However, I really do think for a new "systems language" nowadays, you do want to look at how major security holes occur in practice, and have a good story on how users should avoid them.

ddevault 4y ago
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"...
- 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.
mikepurvis 4y ago
> Java, or Haskell, or Python These are all GC'd languages that run bytecode on an abstract virtual machine. They avoid use-after-free by just not-freeing, if necessary at the cost of leaking unbounded amounts of memory. This doesn't invalidate the point that borrowing isn't the only way to solve this problem, but there are definitely classes of these bugs for which Rust's borrow checker is the only known production-ready solution that still has manual, deterministic memory management.
- 4ad 4y ago
  Your point about GC stands, but I will note that Haskell is a compiled language.
  - eatonphil 4y ago
    And Go and native-image (GraalVM Java compiler) and Poly/ML (on x86) and MLton and OCaml (on x86) and Chicken Scheme and SBCL (and ECL).

throwaway82652 4y ago

You should be implementing a borrow checker or something like it. It's irresponsible not to do that. I'm serious about this. We know how to totally stop most use-after-free bugs during static analysis now, this is a tool that can be implemented in any language, so people should just do it. If you ask me the status quo moved a long time ago. This has nothing to do with Rust. Also I was wrong before and you were out of line. Matthew wasn't trolling, he never said you should be held criminally liable. You just made that criminal part up for no reason. Anyone should be held socially liable and shamed if their project has bad security and they refuse to fix it after they knew about it. I think you would even agree with that.