Re: [Haskell-cafe] SSL support for hackage and cabal

And some of us have been relying on Vincent's tis package for our production code and would very much like to see it in the platform. And surely we do need a cross-platform solution. Chris From: Michael Snoyman Date: Monday, 4 November 2013 06:55 To: Carter Schonwald Cc: Haskell-Cafe Subject: Re: [Haskell-cafe] SSL support for hackage and cabal FWIW, I went through this exact decision making process about 2 years ago when working on TLS support in http-conduit[1] and came to the conclusion that the best choice by far was using Vincent's tls package. I've been very happy with the results. Not only is Yesod used on a number of platforms, but I've shipped commercial software to both Windows and Mac, and having one less system library to worry about saved me lots of pain[2]. [1] Actually, the only reason I ever wrote http-conduit instead of just using HTTP was that I needed TLS support for OpenID, and I could never get the existing TLS-in-HTTP-package solutions to work. [2] An example to the contrary to text-icu, which to this day I cannot reliably get installed on a Windows system. On Mon, Nov 4, 2013 at 8:39 AM, Carter Schonwald wrote:

agreed, would likely be a portability nightmare, and the cabal devs have enough on their plate as is!

On Mon, Nov 4, 2013 at 1:35 AM, Vincent Hanquez wrote:

...

On 2013-11-04 01:02, Donn Cave wrote:

...

How strongly do you feel about the cross platform and dependency issues? Quite ? I think that would be rather bad to have cabal have ssl on unix, but not on MacOSX and Windows.

...

When I needed SSL encryption, I whipped up a little module with foreign calls to OpenSSL. For an ordinary client, which is all I use it for any more, it's a simple interface -- init, connect, read, write, a couple error functions. I have to link -lssl -lcrypto. The great thing about this is, not only do I have a high degree of confidence in the implementation, I don't expect it to _ever_ change in a way that will inconvenience me. If my application ever needs to work on a platform with a different SSL, just need a new module with init/connect/write etc.

Does that seem like a possibility, just write minimal interfaces to existing platform standard SSL implementations, and move on to more interesting problems? Or is this really an area with interesting problems of its own that I'm missing?

I think that's the best alternative (provided wide spread non support for tls), except there's no platform standards (think about chromium, and mozilla cases for a very similar problem), and it's probably going to be "interesting" to maintain (as in it take probably quite a bit of resource for browsers to keep on top).

-- Vincent

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe