5 ms·

I am hoping that Rust will make in-roads into the BSD world, since it interoperates well with C and is much safer by default while not imposing overhead like a

by rhelmer 11y ago

I am hoping that Rust will make in-roads into the BSD world, since it interoperates well with C and is much safer by default while not imposing overhead like a managed language+runtime would. It also has very liberal licensing (GCC being GPL has always been a tough pill for some to swallow, FreeBSD at least has already switched to Clang) https://github.com/rust-lang/rust#license https://github.com/rust-lang/rust#license The OpenBSD folks have done great work through auditing and writing safer code in C, and I agree that using a language that ameliorated at least some of the common mistakes programmers make would be a net positive. Related - this blog from @tedunangst is worth reading, regarding the limit to which even a language like Rust can protect against specific exploits (the OpenSSL "Heartbleed" vulnerability, in this case) http://www.tedunangst.com/flak/post/heartbleed-in-rust http://www.tedunangst.com/flak/post/heartbleed-in-rust

jerf 11y ago
What tedunangst says is true enough in the logical sense, but it makes me nervous in the human sense. Humans seem prone to the following logic failure: 1. Object X frequently removes limbs from the user. 2. Object Y does the same thing, but more safely. 3. Wait, Object Y causes hangnails if you misuse it hard enough. 4. It's OK to keep using Object X! Like many fallacies, this doesn't survive being clearly written out, but I still see it an awful lot.
- rhelmer 11y ago
  I don't know, I think it's a pretty fair treatment - there are links to an advisory that Ted thinks Rust could have prevented (http://www.x.org/wiki/Development/Security/Advisory-2015-02-10/ http://www.x.org/wiki/Development/Security/Advisory-2015-02-...) and to a blog post disagreeing with his http://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look http://tonyarcieri.com/would-rust-have-prevented-heartbleed-...
  - jerf 11y ago
    I am saying tedunangst's treatment is fair. What I don't like is what people in general tend to do with the argument. I am not claiming tedunangst is doing that with the argument.
nickpsecurity 11y ago
I have hopes for Rust, too, in this space. They're making a lot of good design decisions to balance safety & performance. Far as Heartbleed, that sort of thing can be detected using techniques from "information flow control security." Essentially, the programmer labels resources in terms of confidentiality and integrity. The type system, compiler, whatever checks them against a security policy. So, a variable containing confidential data shouldn't be accessed by functionality sending data to public sources. Here's an example from one of the leading groups in the field: http://www.cs.cornell.edu/jif/ http://www.cs.cornell.edu/jif/ That was turned into SIF, Swift, Fabric, and I think Civitas voting system. Swift even auto-partitions the system between client and server side while maintaining confidentiality/integrity policies. Fabric kicks butt on all kinds of issues in the hardest space of them all. So, given the above, I'm sure a problem like Heartbleed in a mere SSL protocol would be trivial to prevent at language level if software and compiler developers merely chose to adopt info-flow security at least for important projects. Note: One can use stuff like that even if not supported in main tool set by creating a mock-up of software in supporting toolset. The abstraction gap presents issues but a problem in one might mean problem in other. Especially for what amounts to covert channel analysis of software.
supdog 11y ago
From what I understand, Rust is not making in-roads into the OpenBSD world for at least these reasons: 1) Rust's use of LLVM means it will not work on some hardware platforms that the OpenBSD folks are committed to run on. 2) The Rust project currently does not offer a long term support release. These are important to the OpenBSD team. Additionally, I am sure that they value the memory safety that Rust offers. I wonder if the OpenBSD team would ever design a systems language?
- rhelmer 11y ago
  Note I said "BSD World" :) FreeBSD is already using LLVM (Clang) instead of GCC, and support fewer platforms - I think this would be a more pragmatic place to push something new like Rust. If it works out there, OpenBSD could audit and import things at their leisure, at least in theory.
- digitalzombie 11y ago
  Why didn't they just use Ada then? Ada have been long before Rust and is a good alternative to C.

by rhelmer 11y ago

jerf 11y ago

What tedunangst says is true enough in the logical sense, but it makes me nervous in the human sense. Humans seem prone to the following logic failure: 1. Object X frequently removes limbs from the user. 2. Object Y does the same thing, but more safely. 3. Wait, Object Y causes hangnails if you misuse it hard enough. 4. It's OK to keep using Object X! Like many fallacies, this doesn't survive being clearly written out, but I still see it an awful lot.

rhelmer 11y ago
I don't know, I think it's a pretty fair treatment - there are links to an advisory that Ted thinks Rust could have prevented (http://www.x.org/wiki/Development/Security/Advisory-2015-02-10/ http://www.x.org/wiki/Development/Security/Advisory-2015-02-...) and to a blog post disagreeing with his http://tonyarcieri.com/would-rust-have-prevented-heartbleed-another-look http://tonyarcieri.com/would-rust-have-prevented-heartbleed-...
- jerf 11y ago
  I am saying tedunangst's treatment is fair. What I don't like is what people in general tend to do with the argument. I am not claiming tedunangst is doing that with the argument.

nickpsecurity 11y ago

I have hopes for Rust, too, in this space. They're making a lot of good design decisions to balance safety & performance. Far as Heartbleed, that sort of thing can be detected using techniques from "information flow control security." Essentially, the programmer labels resources in terms of confidentiality and integrity. The type system, compiler, whatever checks them against a security policy. So, a variable containing confidential data shouldn't be accessed by functionality sending data to public sources. Here's an example from one of the leading groups in the field: http://www.cs.cornell.edu/jif/ http://www.cs.cornell.edu/jif/ That was turned into SIF, Swift, Fabric, and I think Civitas voting system. Swift even auto-partitions the system between client and server side while maintaining confidentiality/integrity policies. Fabric kicks butt on all kinds of issues in the hardest space of them all. So, given the above, I'm sure a problem like Heartbleed in a mere SSL protocol would be trivial to prevent at language level if software and compiler developers merely chose to adopt info-flow security at least for important projects. Note: One can use stuff like that even if not supported in main tool set by creating a mock-up of software in supporting toolset. The abstraction gap presents issues but a problem in one might mean problem in other. Especially for what amounts to covert channel analysis of software.

supdog 11y ago

From what I understand, Rust is not making in-roads into the OpenBSD world for at least these reasons: 1) Rust's use of LLVM means it will not work on some hardware platforms that the OpenBSD folks are committed to run on. 2) The Rust project currently does not offer a long term support release. These are important to the OpenBSD team. Additionally, I am sure that they value the memory safety that Rust offers. I wonder if the OpenBSD team would ever design a systems language?

rhelmer 11y ago
Note I said "BSD World" :) FreeBSD is already using LLVM (Clang) instead of GCC, and support fewer platforms - I think this would be a more pragmatic place to push something new like Rust. If it works out there, OpenBSD could audit and import things at their leisure, at least in theory.
digitalzombie 11y ago
Why didn't they just use Ada then? Ada have been long before Rust and is a good alternative to C.