On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman
I know people have raised security concerns about using the tls package due to lack of testing relative to OpenSSL, but I'm not sure if those arguments are so valid given recent events[5].
Yeah, I've been meaning to mention this issue -- I have definitely been
among those in the past pushing for OpenSSL as the only sensible solution
(conventional crypto wisdom is that you stick to tried and true,
well-tested solutions) but I might change my tune on this. Sure, the
Haskell tls library might potentially be vulnerable to unknown side
chaining or timing attacks (and there is C code in there), but I don't see
much chance of buffer overflows leading to secret key disclosure (!) coming
out of our camp.
Unfortunately the entire Haskell tls/crypto ecosystem doesn't obey the
Hackage package versioning policy and until this is fixed I think that
issue precludes it from being included in the platform.
As far as HTTP clients go there is also http-streams (
http://hackage.haskell.org/package/http-streams) which is itself very nice
and (unsurprisingly) what I would vote for. Given that we already have an
HTTP client library in the platform (even though it's not really so great)
and there are multiple viable alternatives, I don't think we can pick a
replacement to go into the platform yet, especially if it would pull in one
of the streaming libraries. I've considered nominating io-streams for
inclusion into the platform (it's a very nice and high-quality library, if
I do say so myself) but I haven't because the matter simply isn't settled
yet and I don't think it's right to canonize one approach over the others.
G
--
Gregory Collins