GNOME Bugzilla – Bug 614632
No SOCKS proxy support
Last modified: 2010-07-05 12:47:02 UTC
Version: evolution-2.30.0 Hardware Model (on what HW this bug is uncovered): EeePC 1005PE Bug detailed descriptions(behavior, impact, etc) =========================================================== Evolution cannot receive email via proxy network Reproduce Steps(steps,current result, reproduce possibility) =========================================================== (1)Launch evolution email client (2)Config a valid email account (3)Set network proxy in "Evolution Preference" window (4)Try to send/receive emails (5) Expected result: =========================================================== Proxy network should work on Evolution Possible root cause: ===========================================================
possible dupe of bug 578429
I suspect this comes down to a different bug which is: "no SOCKS support"
Federico seems to be on it in his camel-socks-proxy branch. Assigning to him.
The camel-socks-proxy branch is done for now; this is in evolution-data-server. Also, evolution's express2 branch has the code to hook up proxy support in Camel. Both pieces of code are already merged into e-d-s's and evo's master branches. These patches add support for SOCKS4, since that is what the current API in Camel lets us do. We just use the SOCKS4 proxy host/port that is defined in these global GConf keys: /system/proxy/socks_host /system/proxy/socks_port Adding support for SOCKS4a and SOCKS5 requires additional changes to the CamelTcpStream API. These changes are discussed in the big comment in camel-tcp-stream.h.
Created attachment 162673 [details] [review] evolution-data-server-bgo614632-camel-socks-proxy.diff Patchset for evolution-data-server 2.30; adds support for SOCKS4 proxies in Camel.
Created attachment 162674 [details] [review] evolution-bgo614632-camel-socks-proxy.diff Patch for Evolution 2.30; hooks up Gnome's configured SOCKS4 proxy into Camel.
Closing as fixed now that the code is in.
So I guess bug #580341 is now a prerequisite for ditching CamelStream for GIO streams.
Do we need to add SOCKS in UI under network preference which was removed in bug 555888 ?
(In reply to comment #8) > So I guess bug #580341 is now a prerequisite for ditching CamelStream for GIO > streams. No idea about GIO's networking API, but I guess you can "just" convert CamelTcpStream to use GIO underneath, and still have Camel do the proxying itself. When GIO gets proxy support, then you scrap that code in Camel.
*** Bug 578429 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > Do we need to add SOCKS in UI under network preference which was removed in bug > 555888 ? Maybe. However, I think that whole preferences page is redundant. GNOME already provides a capplet in the control center to configure network proxies.
I would really, REALLY love to kill the Network Preferences page.
(In reply to comment #10) > No idea about GIO's networking API, but I guess you can "just" convert > CamelTcpStream to use GIO underneath, and still have Camel do the proxying > itself. When GIO gets proxy support, then you scrap that code in Camel. Oh cool, so the SOCKS stuff is just layered on top. That should work.
(In reply to comment #13) > I would really, REALLY love to kill the Network Preferences page. Why don't we do that? Isn't it totally redundant with GNOME's own GConf keys for proxies? (What does Evo do about Windows? Would GIO obviate that?)
(In reply to comment #14) > Oh cool, so the SOCKS stuff is just layered on top. That should work. SOCKS works like this in Camel right now: 1. Evo calls camel_session_set_socks_proxy(session, host, port) 2. Each provider (pop/imap/nntp/etc) calls camel_session_get_socks_proxy(), and uses the result to call camel_tcp_stream_set_socks_proxy(). 3. The implementation of ::connect() for CamelTcpStream's subclasses sees if there is a proxy configured; if so they connect to it instead of connecting directly to the actual destination host. So if you replace calls to socket()/connect()/read()/write() and the corresponding NSPR functions with calls to GIO, then SOCKS proxies should pretty much just keep working. (3) is uncomfortably cut&pasted across CamelTcpStreamRaw and CamelTcpStreamSSL, unfortunately, because the former uses Unix calls and the latter uses NSPR (plus, the SSL version needs to reset the SSL handshake after connecting to the proxy). That's easy to factor out, I guess, or to completely eliminate if you switch basic I/O to use GIO. In similar spirit, I'd like the pop/imap/etc. providers to avoid having exactly the same cut&pasted code around camel_getaddrinfo(); if (ssl) { yada yada yada; } camel_tcp_stream_set_socks_proxy(); camel_tcp_stream_connect(); If you want to completely scrap CamelStream, that's a bigger job, but it is still Just Refactoring :)
(In reply to comment #15) > Why don't we do that? > > Isn't it totally redundant with GNOME's own GConf keys for proxies? > > (What does Evo do about Windows? Would GIO obviate that?) I'm not exactly sure why it was added to begin with, so I might be overlooking some use case. Need to dig through the archives. If it were per-account I might grudgingly acknowledge some value there, but it's not. If I find it's just a workaround for non-GNOME desktop environments I'll kill it immediately.
(In reply to comment #17) > I'm not exactly sure why it was added to begin with, so I might be overlooking > some use case. Need to dig through the archives. If it were per-account I > might grudgingly acknowledge some value there, but it's not. If I find it's > just a workaround for non-GNOME desktop environments I'll kill it immediately. Yeah... maybe it predates GNOME's capplet. No idea.
It was added to primarily support GW and Exchange (OWA) connector as both use libsoup. Libsoup manages its own socket and hence, adding only to Camel doesn't help both the connectors. And, yes, to begin with, the page was added as a shortcut to support beyond GNOME (including Windows) and the code dates back to 2.12 of Evolution release.
If I attempt to connect to my own mailservers with SOCKS, evolution crashes: camel:ERROR:camel-tcp-stream-ssl.c:1303:connect_to_socks4_proxy: assertion failed: (connect_addr->ai_addr->sa_family == AF_INET) Aborted (core dumped) I assume this was only ever tested with Legacy IP, never IPv6? You should at least support SOCKS5 proxies, which would allow you to request connection to an IPv6 host numerically -- you don't _have_ to ask it to do the DNS lookup for you. And please, *NEVER* push networking code which hasn't been tested with IPv6. It's not hard to set up IPv6; there's really no excuse for it.
It's often the case that you want to use SOCKS for connecting to _some_ destinations, but not others. One idea I've occasionally toyed with is that you could invent an AF_SOCKS address family, and your getaddrinfo() function could return an AF_SOCKS sockaddr containing the original name. That sockaddr then gets passed into the connect() function just like a normal address -- and is handled appropriately there. Since you haven't let individual accounts configure the SOCKS proxy for themselves anyway, having that logic in camel_getaddrinfo() might make a lot of sense -- you can then say "use SOCKS only for addresses within $COMPANY.internal". Or if you're stuck _inside_ the company network, you can perhaps do the opposite.