/pidgin/main: e6c37a5e6666: New dependency: libcurl

[Elliott Sales de Andrade]

On Mon, Oct 1, 2012 at 2:57 PM, Ethan Blanton <elb at pidgin.im> wrote:
> Tomasz Wasilczyk spake unto us the following wisdom:
>> - libcurl perfectly fits into purple event loop (see my
>> implementation); libsoup doesn't seems to provide such possibility,
>> but there is a way to swich GMainContext. However, I still don't know,
>> how to get it working with libpurple
>
> This is an important question to answer if we really care about
> libsoup.  I'm not (personally) sure it's worth the effort.  Perhaps
> Eion can weigh in with why he thinks we should bother with libsoup (or
> anyone else who agrees, I just know he's mentioned it).
>

I point out libsoup because it's already used by WebKit, which is an
advantage for Pidgin only, really. It may not be the best option.
Certainly getting the mainloop handling is important for anything
other than Pidgin. Also, I'm not sure how many of the useful things I
see now exist in the older versions that we may need to use.

After looking through libsoup, I'm wondering if bumping glib
requirements so we can use gio functions throughout may be easier. But
I haven't looked into it entirely.

>> - libcurl doesn't provide any callbacks to SSL verifying functions.
>> Although, it provides CURLOPT_CAINFO, CURLOPT_ISSUERCERT,
>> CURLOPT_CAPATH, which can allow us to inject our internally setup
>> certs
>
> I don't know enough about our current CA handling to know if this is
> viable.  I think we manually merge multiple CA dirs, right?
>

I don't think you can override libsoup's handling of SSL certificates.
However, you can set SSL handling to be less strict, and examine any
possible errors before continuing with the rest of the connection. I
believe you can add an additional data certificate store, but I
haven't checked what exists in older versions.

>> - libcurl provides callback function for creating a socket, but it
>> have to return socket fd at once (libpurple returns estabilished
>> connection within a callback) AND it gets only ip addresses to connect
>> to (don't get http proxy benefits with passing an url). However, it
>> supports all proxies, that libpurple supports (see CURLOPT_PROXYTYPE)
>> - we can just inject it
>
> There are a couple of things to watch, here.  First off, requiring
> synchronous connect is bad, because it means libcurl is doing
> synchronous DNS lookup followed by connect(), which can stall the UI.
> We really want to avoid that if we can.  Second, we're a bit pickier
> about some of the proxy types than libcurl is; for example, we
> restrict DNS to activities that we can pass through a SOCKS 5 remote
> lookup when we use the Tor proxy type, to avoid leaking information
> onto the local network about Tor-sheltered activity.
>

By implementing a SoupProxyURIResolver, you can override DNS stuff.
What other proxy stuff do we need exactly?

>> - I think, libcurl may be hacked to operate on "faked" sockets, to
>> force it using our socket creating function (proxy api), but I think
>> it may lead to more problems than it solves. See
>> CURLOPT_WRITEFUNCTION, CURL_WRITEFUNC_PAUSE, CURLOPT_READFUNCTION,
>> CURLOPT_OPENSOCKETFUNCTION (this one could return our "faked" socket
>> identifier instead of real socket).
>
> Can we use *real* sockets here?  I assume the problem is that the open
> socket function has to return a "real" fd in that case, and we don't
> have one...  Once our sockets are open, though, curl can use normal
> read()/write()/etc. on them.  That is, assuming it understands
> SO_NONBLOCK sockets.
>

Same question, I guess.

>> - I don't see any possibility to inject our DNS resolver functions to
>> libcurl
>
> :-(
>
>> Another thought about totally wrapping http library into our
>> abstraction: there is really a lot to wrap. Also, if we don't wrap
>> _everything_ we should to and make an option to provide user-specified
>> http plugin for libpurple (I mean: we make plugin side also a part of
>> API), there may be a necessity to wait for libpurple 4.0.0 to
>> introduce such new features (require them from such http support
>> plugins).
>
> I don't think this is necessary (wrapping everything).  However, if it
> is, and we want to provide a http plugin interface similar to our SSL
> plugin interface, this can go into 3.0.0 without problem.  We haven't
> frozen that API.
>
> Ethan
>

-- 
Elliott aka QuLogic
Pidgin developer