TLS/SSL implementation in Haskell

Re:TLS/SSL implementation in Haskell by bad_user on Wednesday April 09, 2014 @08:52AM (#7558926)

Even when Java fails at runtime, because it forces garbage collection for memory management, buffer overflows and dangling pointers can't really happen - yes, if you're not careful, the process can still have unexpected behavior, or it might crash. Actually, the Heartbleed bug wouldn't have been such an issue if OpenSSL wouldn't use its own wrapper around malloc/free (at the very least, the malloc/free underneath would be a variable in that equation), e.g. http://article.gmane.org/gmane.os.openbsd.misc/211963

So while I love strong and static type systems, the issue at play here is memory safety - the very reason for why people still use C/C++ is the same reason for why Heartbleed happened.

[ Parent | on HN ]

Re:TLS/SSL implementation in Haskell by TheLoneWolfling on Wednesday April 09, 2014 @03:24PM (#7561678)

You're assuming that the JVM is secure. But yes, good point.

Although I'd argue that a truly strong type system should also catch problems with pointers. The compiler should try to prove that any pointer access/arithmetic can or cannot cause undefined behavior - if it could cause undefined behavior, emit a compiler error, if it cannot prove that it won't cause undefined behavior, emit a warning and insert a runtime check.

(Still have the underlying "unsafe" functions. But group them into part of the standard library as an "unsafe" package.)

[ Parent | on HN ]

Re:TLS/SSL implementation in Haskell by iopq on Thursday April 10, 2014 @03:57AM (#7564747)

That's what Rust does. Its type system prevents all memory and concurrency errors. But to be able to have a self-hosting compiler (and to be able to write an OS in it) there's also `unsafe` blocks.

[ Parent | on HN ]