On Tue, Apr 8, 2014 at 6:29 PM, Gregory Collins <greg@gregorycollins.net> wrote:

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman <michael@snoyman.com> wrote:

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.

I'm sure you can guess that I disagree with this statement. But I also find it absurd in the given context: the Haskell Platform package we're discussing right now (cgi) doesn't follow the PVP!

Beyond just trying to force the rest of the world to adhere to the PVP, what actual reason is there to require Haskell Platform packages adhere to the PVP? I assume you're referring to the fact that tls doesn't include upper bounds on its dependencies, because it certainly *does* follow PVP's versioning guidelines on its own version number. But once a package is included in the platform, there's no opportunity for build failures since the platform will be locking down versions of all its dependencies.

So besides trying to find another means of enforcing PVP adherence on the rest of us, what value is there in this new requirement?

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.

http-client has no dependency on any streaming data library. The codebase- while it's moved from a few different libraries over the years- has been publicly available since 2010[1]. It has bindings for tls and openssl, as well as interfaces for conduit and pipes. It has a large number of packages on Hackage already depending on it (at least 104[2] via http-conduit, though there are other libraries that depend on http-client directly). None of this touches on the technical merits of the two libraries; in particular, http-client provides a much more robust connection sharing mechanism than what is available in http-streams.

Michael

[1] http://hackage.haskell.org/package/http-enumerator-0.0.0

[2] http://packdeps.haskellers.com/reverse/http-conduit