[Haskell-cafe] SSL support for hackage and cabal

[Chris Dornan]

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 <michael at snoyman.com>
Date:  Monday, 4 November 2013 06:55
To:  Carter Schonwald <carter.schonwald at gmail.com>
Cc:  Haskell-Cafe <haskell-cafe at haskell.org>
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
<carter.schonwald at gmail.com> 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 <tab at snarc.org> 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>> <http://www.haskell.org/mailman/listinfo/haskell-cafe>
> 
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20131104/9f9b1696/attachment.html>