Making cabal-install SSL capable

[Michael Snoyman]

On Tue, Apr 28, 2015 at 4:22 PM 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...).
>
>
It may be worth looking at the reverse dependencies and download counts on
this. But more importantly: I am most certainly not proposing that
http-client be part of the platform. I discussed this already with Duncan
last week: I have no idea why having the libraries in the platform should
be necessary for a dependency of an executable.


> 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)
>
>
So to translate: since there are two good libraries for doing HTTP client
side calls that both have TLS support, we can use neither of them, and must
instead continue using the library we know to be inferior, *and* do extra
dev work to add in TLS support, an endeavor which at least anecdotally has
failed once before?

By the way: I'm unaware of any violent disagreement around http-client vs
http-streams. There are certainly differences between the libraries which
I'd be happy to explore with others (in a separate thread, this isn't the
place), but I think the possibility for a community brawl on this is
slightly overstated.


> 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...
>
>
I agree on that front. I think that Hackage should turn away all uploads
that aren't TLS-secured, and should make that change ASAP.


>  [1]: Are those issues documented somewhere btw? Could that it be
>       addressed via minghc?
>
>
>
There's not really anything to document. It's a matter of having to install
the DLLs correctly, which people find difficult without a package manager.
I'm in favor of supporting this situation better with MinGHC, but it would
need someone else to spearhead it; I frankly have no itch to scratch here,
since I'm already quite happily using the tls package.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150428/0e512091/attachment-0001.html>