On Sunday, 4 May 2014 at 13:29:34 UTC, Meta wrote:
On Sunday, 4 May 2014 at 08:34:20 UTC, Daniele M. wrote:
I have read this excellent article by David A. Wheeler:
http://www.dwheeler.com/essays/heartbleed.html
And since D language was not there, I mentioned it to him as a
possible good candidate due to its static typing and related
features.
However, now I am asking the community here: would a D
implementation (with GC disabled) of OpenSSL have been free
from Heartbleed-type vulnerabilities? Specifically
http://cwe.mitre.org/data/definitions/126.html and
http://cwe.mitre.org/data/definitions/20.html as David
mentions.
I find this perspective very interesting, please advise :)
While D is a somewhat safer language by *default*, it makes it
fairly easy to escape from the safe part of the language and
write unsafe code (array bounds checking can be turned off even
for @safe code). Seeing as the OpenSSL devs went as far as to
write an a buggy, custom implementation of malloc for a speed
gain, turning off array bounds checking and ignoring @safe
seems like the first thing they would do. The only language I
would really trust is one in which it is impossible to write
unsafe code, because you can then know that the developers
can't use such unsafe hacks, even if they wanted to.
You are right, devs would eventually abuse everything possible,
although it would make it for sure more visible: you cannot
advertize an un-@safe library as @safe, although I agree that a
lot depends from devs/users culture.
