Making cabal-install SSL capable

[Gershom B]

I don’t think the issue of http libraries as a foundational core library is very important. I suspect it would be possible to do a minimal http transport over tls, just as one can over HsOpenSSL, if that is how we decided to go. In the meantime, here are the first-order dependencies of tls alone, for comparison. I imagine there are a few others pulled in as well, in the second-order deps.

                     cereal >= 0.4
                   , byteable
                   , data-default-class
                   -- crypto related
                   , cryptohash >= 0.6
                   , crypto-random >= 0.0 && < 0.1
                   , crypto-numbers
                   , crypto-cipher-types >= 0.0.8
                   , crypto-pubkey >= 0.2.8
                   , crypto-pubkey-types >= 0.4
                   , cipher-rc4
                   , cipher-des
                   , cipher-aes >= 0.2 && < 0.3
                   -- certificate related
                   , asn1-types >= 0.2.0
                   , asn1-encoding
                   , x509 >= 1.5.0 && < 1.6.0
                   , x509-store >= 1.5.0
                   , x509-validation >= 1.5.1 && < 1.6.0
                   , async

More troublesome, I recall that the current scheme for cabal is that it is fully bootstrappable by only depending on GHC base libs and “vendored” dependencies?

In that case, perhaps we really should lean only towards the “shell out” solution. Or, I suppose, we could hide the ssl implementation behind a flag — but that feels rather awkward in comparison.

So let’s try this: can anybody suggest any _downside_ to the “shell out” solution?

—Gershom


On April 28, 2015 at 9:22:22 AM, Herbert Valerio Riedel (hvriedel at gmail.com) wrote:
> On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote:
>  
> [...]
>  
> > I have no intention of playing the "minimal dependency" game (though I
> > don't mind dropping data-default, which accounts for 6 of the dependencies
> > listed there). I will point out- as Gershom already did- that in many cases
> > it's likely easier to install a few extra Haskell packages than it is to
> > pull in OpenSSL as a dependency, especially on Windows. (And that's
> > ignoring the fact that http-client-openssl exists.)
>  
> While I do appreciate the technical issues resulting from HsOpenSSL on
> Windows[1], I'll be frank and admit that there's a "political" aspect
> that worries me with such a large number of added dependencies imported
> into the cabal project in one go, as that would promote (or at the very
> least bias) one specific family of multiple competing HTTP-client
> abstractions into the Haskell Platform through the back-door (assuming
> the idea of the HP hasn't been abandoned -- I may not be up to date
> regarding that debate), and make it a fait accompli without having
> actually had any agreement on it (which I admit may never be reached, as
> the associated communities involved have grown quite large by now and
> may disagree quite violently on basic design choices...).
>  
> That's why I suggested HTTP+HsOpenSSL (which tbh is not my favorite HTTP
> library), as that would be the neutral choice regarding HTTP-libraries
> at the foundational core library level. Alternatively, Gershom's
> suggestion to shell out to curl(1)/wget(1)/etc would equally achieve
> impartiality regarding HTTP-libraries (and probably work better on
> Windows too)
>  
> PS: We shouldn't forget that there's also an existing deployed
> cabal-install user-base we can't get rid off so easily, which may
> still leak unencrypted basic-auth credentials for the years to
> come. Just saying...
>  
> [1]: Are those issues documented somewhere btw? Could that it be
> addressed via minghc?
>  
> Cheers,
> hvr
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>