Re: Gearing up (again) for the next release: 2014.2.0.0

On 2014-04-08 16:29, Gregory Collins wrote:

On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman mailto: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.

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