Gearing up (again) for the next release: 2014.2.0.0

[Carter Schonwald]

so it sounds like theres a clear agreement to not include a new http lib in
HP this cycle? :))))


On Tue, Apr 8, 2014 at 11:54 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> 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
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140408/a9587aca/attachment.html>