On Sunday, 4 May 2014 at 10:23:38 UTC, Jonathan M Davis via
Digitalmars-d wrote:
On Sun, 04 May 2014 08:34:19 +0000
"Daniele M. via Digitalmars-d" <[email protected]>
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 :)
@safe code protects against indexing an array out-of-bounds.
So, if OpenSSL
had been implemented in D, and its heartbeat feature used @safe
code, then
heartbleed would not have been possible. As soon as an attempt
was made to
index passed the end of the array, it would have thrown a
RangeError and
killed the program.
This is what I thought too.
Now, even if OpenSSL had been implemented in D, if it had used
@system or
@trusted code for its heartbeat feature, then it could have had
the bug just
as easily in D as it did in C. And given all of the horrible
practices in
OpenSSL, I very much doubt that having it written in D would
have prevented
much, because anyone making the choices that the OpenSSL folks
have been
making would likely have ended up with horrible D code which
was mostly
@system and probably doing all kinds of things that are
inherently risky,
forgoeing many of the benefits that D provides.
I think that it's safe to say that D makes it easier to catch
problems like
this, but it doesn't entirely prevent them, and bad programming
practices
can pretty much always get around protections that the language
provides
unless the language provides no ways around those protections
(which isn't
the case in D, because it's a systems language and needs to
provide low-level
access and features for those programs that need them - it just
doesn't use
those by default).
I should have said: a D implementation of OpenSSL *without* the
malloc sorcerery, sorry for leaving it out of OP. Reason I'd like
to ignore that for this discussion is that I consider it a bug.
And we are all in the post-heartbleed scenario now so it looks
huge, but Theo De Raadt already said it all, nothing to add on it.
And then comes my next question: except for that malloc-hack,
would it have been possible to write it in @safe D? I guess that
if not, module(s) could have been made un-@safe. Not saying that
a similar separation of concerns was not possible in OpenSSL
itself, but that D could have made it less development-expensive
in my opinion.
If I had more time, I'd actually be tempted to write an SSL
implementation in
D, but even if I were to do an excellent job of it, it would
still need to be
vetted by security experts to make sure that it didn't have
horrible security
bugs in it (much as it would be likely that there would be
fewer thanks to
the fact that it would be writen in D), and I suspect that it's
the kind of
thing that many people aren't likely to trust because of how
critical it is.
Nobody would expect/trust a single person to do this job :P
Working in an open source project would be best.
So, I don't know how good an idea it is at this point for
someone to write
an implementation of SSL or TLS in D. Certainly, it's the type
of thing where
we've generally tried to wrap existing C libraries in order to
avoid having
to spend the time, effort, and expertise on in order to fully
implement it
ourselves. The Go guys did it, but if I understand correctly,
the fellow that
did it was one of the OpenSSL developers, so presumably he's
already very
familiar with all of the ins and outs of SSL, and I don't know
if any of us
here are (I'm certainly not - if I were doing it, I'd pretty
much just have
to go off of its associated RFCs, for better or worse).
I wasn't aware of this effort, interesting experiment.
At this point though, if I were looking at using an existing
implementation
of SSL, I'd probably be looking at GnuTLS rather than OpenSSL
given how
horrible OpenSSL's codebase is. I don't know that GnuTLS is any
better, but
it wouldn't be hard for it to be. OpenSSL is horrible both with
regards to
its implementation and its API, and we'd all be better off if
something
better replaced it (be it GnuTLS or something else).
I would pick LibreSSL:
http://www.libressl.org/
And merge patches as their progress goes on.
Unfortunately, even if
something better _were_ written in D, it's probably only the D
folks who
would benefit, since it's not terribly likely at this point
that very many
folks are going to wrap a D library in order to use it another
language.
Here I don't completely agree: if we can have a binary-compatible
implementation done in D, then we would be able to modify
software to eventually use it as a dependency. I don't see the
necessary D dependencies as prohibitive here.
However, regardless of whether we ever end up with an SSL
implementation in D,
I started this discussion just for the thought exercise, because
I think it can give a few positive leads, but nice to see that
other people too thought about a possible implementation :)
I think that in the long run, D will show itself to be much,
much better than
C or C++ at writing code that has a low number of security bugs.
- Jonathan M Davis
Thanks for your post Jonathan, however I believe that attempts
like Go's are what makes a language more real and less
theoretical. The field test of D on system-level software would
be in my opinion useful and sometimes I think the sooner the
better, to eventually modify the evolution of this beautiful
language (if there's still a viable window for this).
