3 ms·

> That's a fair question imo. Are you willing to be convinced that you're wrong? Like completely, totally wrong about the value and goodness of "memory safety

by geocar 4y ago

> That's a fair question imo. Are you willing to be convinced that you're wrong? Like completely, totally wrong about the value and goodness of "memory safety". Premise. Conclusion. Everything. If you're not, then no, it's not a fair question at all. It's just bait.

Ygg2 4y ago
> Are you willing to be convinced that you're wrong? Yes. But you have to prove that your value proposition, doesn't lead to horrible failure down the line. I.e. We need to make software fast, security be damned is not a valid argument.
- geocar 4y ago
  > But you have to prove that your value proposition, doesn't lead to horrible failure down the line. No I do not. My software is done, it has run for decades on the Internet, making me money; For whatever you could mean by "horrible failure", what I am doing either doesn't lead to it, or it's clearly not that bad. > ... is not a valid argument We're not having an argument; You want to ask a question, I can give you an answer, but there's nothing here to argue: I'm ``using a "memory unsafe"´´ language because I can write secure programs that run quickly with them, and I don't live in a Harrison Bergeron world. This is about why you can't yet, and really doesn't have anything to do with me.
  - pjmlp 4y ago
    Then you thankfully don't have to worry about your local jurisdiction catching up with the times of software liability. https://www2.deloitte.com/dl/en/pages/legal/articles/it-sicherheitsgesetz-kritis-verordnung.html https://www2.deloitte.com/dl/en/pages/legal/articles/it-sich... Eventually all countries will have similar laws.
    - geocar 4y ago
      Germany is not going to make illegal the selling of software that contains components written in C.
      - pjmlp 4y ago
        No, but it requires covering for fixes, free of charge, in special security critical infrastructures. Software company bares the cost of producing faulty software. When it touches the bank, many companies will start considering alternatives. In fact, this is what drove Microsoft et al to start finally embracing other stacks, the amount of money burned fixing exploits for free in OS updates.
  - Ygg2 4y ago
    > I'm ``using a "memory unsafe"´´ language because I can write secure programs that run quickly with them, and I don't live in a Harrison Bergeron world. Did you prove it mathematically? Did you wrap it in Rust API and use miri to inspect for UB? Did you ran it through ASAN, MSAN, STACK, etc? All UB/platform-specific behavior has been accounted for? So you ran fuzzers for days-weeks? What issues did it uncover? Do your test coverage account for all cases and most input variations? Or is this a case of ``I think I can write secure programs``. There is a light-year-wide trench between thinking and proving you can do something. And it still needs to break is not a guarantee.
    - kayleee 4y ago
      Rust does not have a formally verified compiler - while C does. So if you want mathematically proven correct code, use C.
    - geocar 4y ago
      > There is a light-year-wide trench between thinking and proving you can do something. It's easy to prove something isn't secure, one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper https://www.opencve.io/cve?vendor=hyper and so on and so on but there's nothing that's ever going to prove that something is secure from everything. Thinking is the best anyone can do, and one of the most important things you can think about is where exactly you're going to draw the line.
      - Ygg2 4y ago
        > Thinking is the best anyone can do No, it's not. That's why I am asking for clarification. By testing, proving programs, running fuzzers, running sanitizers, and various other tooling you reduce the chance of problems to an acceptable level. You can't be perfectly safe, but nothing doing anything isn't acceptable behavior in face of preventable risk. > one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper https://www.opencve.io/cve?vendor=hyper Sure, writing unsafe code is hard. And from what I see most of these issues relate to old versions of Rust having unsound issues that were fixed at later point. > In the standard library in Rust before 1.52.0, > In the standard library in Rust before 1.51.0, > In the standard library in Rust before 1.19.0, ... Basically by upgrading your Rust version, your code becomes less and less buggy over time, which is not something C can boast about (modern C++ is safer but still a far cry from what is achiveable in let's say Java).

by geocar 4y ago

Ygg2 4y ago

> Are you willing to be convinced that you're wrong? Yes. But you have to prove that your value proposition, doesn't lead to horrible failure down the line. I.e. We need to make software fast, security be damned is not a valid argument.

geocar 4y ago
> But you have to prove that your value proposition, doesn't lead to horrible failure down the line. No I do not. My software is done, it has run for decades on the Internet, making me money; For whatever you could mean by "horrible failure", what I am doing either doesn't lead to it, or it's clearly not that bad. > ... is not a valid argument We're not having an argument; You want to ask a question, I can give you an answer, but there's nothing here to argue: I'm ``using a "memory unsafe"´´ language because I can write secure programs that run quickly with them, and I don't live in a Harrison Bergeron world. This is about why you can't yet, and really doesn't have anything to do with me.
- pjmlp 4y ago
  Then you thankfully don't have to worry about your local jurisdiction catching up with the times of software liability. https://www2.deloitte.com/dl/en/pages/legal/articles/it-sicherheitsgesetz-kritis-verordnung.html https://www2.deloitte.com/dl/en/pages/legal/articles/it-sich... Eventually all countries will have similar laws.
  - geocar 4y ago
    Germany is not going to make illegal the selling of software that contains components written in C.
    - pjmlp 4y ago
      No, but it requires covering for fixes, free of charge, in special security critical infrastructures. Software company bares the cost of producing faulty software. When it touches the bank, many companies will start considering alternatives. In fact, this is what drove Microsoft et al to start finally embracing other stacks, the amount of money burned fixing exploits for free in OS updates.
- Ygg2 4y ago
  > I'm ``using a "memory unsafe"´´ language because I can write secure programs that run quickly with them, and I don't live in a Harrison Bergeron world. Did you prove it mathematically? Did you wrap it in Rust API and use miri to inspect for UB? Did you ran it through ASAN, MSAN, STACK, etc? All UB/platform-specific behavior has been accounted for? So you ran fuzzers for days-weeks? What issues did it uncover? Do your test coverage account for all cases and most input variations? Or is this a case of ``I think I can write secure programs``. There is a light-year-wide trench between thinking and proving you can do something. And it still needs to break is not a guarantee.
  - kayleee 4y ago
    Rust does not have a formally verified compiler - while C does. So if you want mathematically proven correct code, use C.
  - geocar 4y ago
    > There is a light-year-wide trench between thinking and proving you can do something. It's easy to prove something isn't secure, one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper https://www.opencve.io/cve?vendor=hyper and so on and so on but there's nothing that's ever going to prove that something is secure from everything. Thinking is the best anyone can do, and one of the most important things you can think about is where exactly you're going to draw the line.
    - Ygg2 4y ago
      > Thinking is the best anyone can do No, it's not. That's why I am asking for clarification. By testing, proving programs, running fuzzers, running sanitizers, and various other tooling you reduce the chance of problems to an acceptable level. You can't be perfectly safe, but nothing doing anything isn't acceptable behavior in face of preventable risk. > one need only an example e.g. https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=rust-lang https://www.opencve.io/cve?vendor=hyper https://www.opencve.io/cve?vendor=hyper Sure, writing unsafe code is hard. And from what I see most of these issues relate to old versions of Rust having unsound issues that were fixed at later point. > In the standard library in Rust before 1.52.0, > In the standard library in Rust before 1.51.0, > In the standard library in Rust before 1.19.0, ... Basically by upgrading your Rust version, your code becomes less and less buggy over time, which is not something C can boast about (modern C++ is safer but still a far cry from what is achiveable in let's say Java).