Making cabal-install SSL capable

[Herbert Valerio Riedel]

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