Gearing up (again) for the next release: 2014.2.0.0

[Michael Snoyman]

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

>
> On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman <michael at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140408/05391604/attachment-0001.html>