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 <mich...@snoyman.com>wrote: > > > > On Tue, Apr 8, 2014 at 6:29 PM, Gregory Collins > <g...@gregorycollins.net>wrote: > >> >> On Tue, Apr 8, 2014 at 5:10 PM, Michael Snoyman <mich...@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 > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > >
_______________________________________________ Haskell-platform mailing list Haskell-platform@projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform
