3 ms·

Since Rust does not provide sec-libs in standard distribution nor they are available in larger ecosystem, Rust benefits seems theoretical to me. As with other t

by geodel 11y ago

Since Rust does not provide sec-libs in standard distribution nor they are available in larger ecosystem, Rust benefits seems theoretical to me. As with other things in theory C/C++ code could also avoid memory/security issues.

bluejekyll 11y ago
They do exist in the larger ecosystem, they are just very young. Also, we devs have had "don't build your own crypto" beaten into our heads so often lately that I think people are generally wary of starting new, or using new, projects that haven't already been battle hardened. I've looked at the OpenSSL code, and I have to say that it's not well documented in many cases and easy to make mistakes in it's usage. The rules on when locks are needed vs. not are not always clear, and then the ownership of memory is as confusing as it's always been in C. This is where something like Rust would shine just by cleaning up these interfaces. The Rust OpenSSL bindings, http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ , for example are very sane, and it's difficult to screw up the usage.
- geodel 11y ago
  Do you mean Rust-openssl bindings will not require patching openssl for Rust apps in case vulnerabilty? In that case Rust surely helps applications written in it.
dfc 11y ago
What are "sec-libs"? From the other reply it seems "sec-libs" are the hip mounted pouches of enchanted crypto dust so you can sprinkle it around and get "security".
pcwalton 11y ago
I don't see any other way to read this other than "there's no point in rewriting security code in Rust because security code in Rust hasn't been written yet". That, obviously, doesn't make sense to me.
- geodel 11y ago
  You do not see any other way to read because you are looking to argue over innocuous statement which is not even false. Security code in Rust could be great and I will be happy if and when it is available for general use.
  - eridius 11y ago
    I agree with pcwalton, that's how I read it too. The context of this thread is security vulnerabilities in OpenSSL, so it's quite reasonable to read your parent comment exactly as pcwalton did.

by geodel 11y ago

bluejekyll 11y ago

They do exist in the larger ecosystem, they are just very young. Also, we devs have had "don't build your own crypto" beaten into our heads so often lately that I think people are generally wary of starting new, or using new, projects that haven't already been battle hardened. I've looked at the OpenSSL code, and I have to say that it's not well documented in many cases and easy to make mistakes in it's usage. The rules on when locks are needed vs. not are not always clear, and then the ownership of memory is as confusing as it's always been in C. This is where something like Rust would shine just by cleaning up these interfaces. The Rust OpenSSL bindings, http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ http://sfackler.github.io/rust-openssl/doc/v0.7.10/openssl/ , for example are very sane, and it's difficult to screw up the usage.

geodel 11y ago
Do you mean Rust-openssl bindings will not require patching openssl for Rust apps in case vulnerabilty? In that case Rust surely helps applications written in it.

dfc 11y ago

What are "sec-libs"? From the other reply it seems "sec-libs" are the hip mounted pouches of enchanted crypto dust so you can sprinkle it around and get "security".

pcwalton 11y ago

I don't see any other way to read this other than "there's no point in rewriting security code in Rust because security code in Rust hasn't been written yet". That, obviously, doesn't make sense to me.

geodel 11y ago
You do not see any other way to read because you are looking to argue over innocuous statement which is not even false. Security code in Rust could be great and I will be happy if and when it is available for general use.
- eridius 11y ago
  I agree with pcwalton, that's how I read it too. The context of this thread is security vulnerabilities in OpenSSL, so it's quite reasonable to read your parent comment exactly as pcwalton did.