[Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

Thomas Davie tom.davie at gmail.com
Mon Oct 11 04:20:48 EDT 2010

> While I agree with the potential benefits, I also worry that you will
> end up making something that is far less well tested in practice. For
> widely used and fairly low-level libraries like gnutls, openssl and
> zlib, I'm just skeptical that the benefits outweigh the risks and costs.
> Anyway, it's just a feeling. Please do prove me wrong :-)

This certainly isn't a proof by a long shot, but my feeling on at least low-level libraries is exactly the reverse of this.

C libraries are usually designed to be extremely stateful (this certainly includes openssl), and because of that any Haskell wrapper for them ends up being heavily IO based.  The result of this is that any code that incorporates it ends up being trapped in an IO mess to do essentially pure (yes, I know the arguments about IO being pure, you know what I mean) things.  It's precisely these libraries that we need not just implemented in a "native" way, but designed in a pure, beautiful, simple way for Haskell.

While I can see your point about potentially introducing new security holes, and producing much less trusted code, I feel having tidy, pure libraries that we can all integrate into our Haskell is a benefit that far outweighs this.  Especially when we have nice things like the type system, which can be used to alleviate many of the security worries.

Tom Davie

More information about the Haskell-Cafe mailing list