Making cabal-install SSL capable

[Gershom B]

Ok, on my "https" branch here: https://github.com/gbaz/Cabal/tree/https

We have some initial support for multibackend downloads and uploads both.
Lots of bits are still missing, but the basic downloads work with curl and
wget both, and the basic uploads with curl.

The code regarding uploading build reports (which isn't in use anyway) is
now commented out temporarily.

Any work at adding other backends or further improving these (note the many
TODO comments littering the code) can hopefully build on this. In
particular, note there's an HttpTransportType, and a function
`findHttpTransport`. In turn both `getHTTP` and `uploadToURI` now call this
function, then case on the result to dispatch to different transports. All
the transport specific logic should now be localized to those two places.

This code is still rather ugly and could use some cleanup. But it should
provide an extension point for using other https layers as well.

On top of that, I haven't tackled the issue of making choice of transport
configurable instead of just doing auto-discovery in a fixed order. It
seems to me that this is something that could be added to the config file,
or a command line flag, or both. So anyone that wants to fixate on that
part of the problem, feel free to jump in :-)

For my part, I wanted to get this out there to help anyone else interested
in adding a transport. At this point, I intend mainly to just clean up what
exists, fill in the powershell (and possibly bitsadmin) transport for
windows, and then reenable HTTP as a fallback layer in some fashion (with
warnings or confirmation or something). (I had commented out the layer
entirely to make sure I wasn't missing any uses of it).

Again, normally I wouldn't be sharing something in this halfway shape, but
it seems useful to make it available for others interested in doing related
work.

Cheers,
Gershom


On Tue, May 5, 2015 at 10:15 AM, Gershom B <gershomb at gmail.com> wrote:

> Note that I’ve started some refactorings to support curl/wget/etc already.
> I’m not sure how best to keep these patches from stepping on one another’s
> toes. I’ll try to get my stuff to an unfinished, untested stopping point
> where nonetheless there is a clear extension point, and then perhaps a fork
> off of that branch would make sense?
>
> —Gershom
>
>
> On May 5, 2015 at 7:29:21 AM, Mikhail Glushenkov (
> the.dead.shall.rise at gmail.com) wrote:
> > Hi,
> >
> > On 4 May 2015 at 08:31, Michael Snoyman wrote:
> > > Just a little update on this. I pinged the author of publicsuffixlist
> > > (necessary for proper cookie domain handling) about removing the
> > > data-default dependency, and after discussion we decided to just merge
> the
> > > code into http-client instead. With that change, the full dependency
> list
> > > for http-client-openssl is in fact smaller that http-streams:
> >
> > I think we would accept a patch making cabal-install depend on
> > http-client or http-streams if it was enabled with a flag.
> > Refactorings required to make this work would also make it simpler to
> > add support for curl/wget/whatever.
> > _______________________________________________
> > cabal-devel mailing list
> > cabal-devel at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20150505/102c251a/attachment.html>