Gearing up (again) for the next release: 2014.2.0.0

[Vincent Hanquez]

On 2014-04-08 16:29, Gregory Collins wrote:
>
> On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman <michael at snoyman.com 
> <mailto: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.
>

First of, you might want to read up on the difference between the 
definition of policy and rules/law. "obey" doesn't have its place here.

Second, the tls/crypto ecosystem is following most of the PvP apart from 
"3 Dependencies in Cabal".

Third, The PvP doesn't actually *enforce* any requirements on 
dependencies. I can only see CAN, SHOULD, MAY in the section 3.
On the other hand, you can find MUST in section "2 Versions numbers", 
and as far I'm concerned the tls/crypto ecosystem is following each 
requirements in this section.

Last, I don't have the luxury of time, and as the single maintainer of 
16 packages of many thousands line of code (and many other packages if 
you don't count tls/crypto), I'ld rather spend my free unpaid time doing 
something useful (adding features, bugfixing,..) for the many currents 
users [1], than playing the upper-bound-catch-up game. When those rare 
breakage happens I get notification from the wonderful stackage and 
usually fix it in the day or so.

> 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.
>

I find it ironic that you'ld rather enforce the PvP requirement 
(rationale 8.6) than the operating system one (rationale 8.4), and in 
the process leave the many windows users [2] in the dust with 
http-streams [3], for so called "violations" of part of the PvP with 
dubious interests.

[1] https://hackage.haskell.org/packages/top  " tls    6647, 
HsOpenSSL    563"
[2] http://www.haskell.org/pipermail/ghc-devs/2014-April/004455.html
[3] Unless you're planning to also vote for requiring/building openssl 
on windows (good luck with that !) as part of the windows haskell platform ?

-- 
Vincent