Gearing up (again) for the next release: 2014.2.0.0

[Michael Snoyman]

I don't think either of us was actually proposing it for the HP, and
certainly not for this cycle. I was actually surprised that Mark mentioned
an HTTP client library at all, given that HTTP is already in the platform.
But if there's interest in replacing it in a later cycle, I would propose
http-client.


On Tue, Apr 8, 2014 at 7:11 PM, Carter Schonwald <carter.schonwald at gmail.com
> wrote:

> 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/20140409/e9550fed/attachment.html>