Fixing proxy support in Fedora (was Re: Orphaning few packages)
nathaniel at natemccallum.com
Thu Jun 6 16:17:04 UTC 2013
On Thu, Jun 6, 2013 at 6:55 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Wed, 2013-06-05 at 12:08 +0800, Christopher Meng wrote:
> > libproxy taken.
> I'm also very interested in libproxy. Would you mind if I comaintain it?
> I've been meaning to deal with proxy configuration in Fedora for a
> while. For those who use an environment where *all* external access has
> to be through proxies, Fedora is just horrid to use. The out-of-the-box
> behaviour for *every* HTTP client application is fairly much broken, and
> you have to manually configure *each* of them to make them work.
> Repeatedly, each time you enter or leave that horrid proxy-requiring
> Libproxy, or something like it, is the solution to this. What we really
> need to happen is:
> - NetworkManager picks up proxy information (from DHCP, VPN server,
> autoproxy or explicit configuration for the connection in use)
> - *EVERY* application just asks "what proxy should I use for this
> URL" by default, unless it's explicitly configured otherwise.
> And thus, in one fell swoop, the problem is solved.
> In fact the original libproxy is fairly horrid. It's an overcomplex C++
> monstrosity which runs the full JS interpreter in the context of *every*
> application which ever needs to check if it needs to use a proxy.
I agree. And I wrote it. :(
Unfortunately, the JS interpreter can't disappear. WPAD is *very* widely
deployed and requires it. We can mitigate it by stuffing it in a session
> There's a much saner, ABI-compatible, replacement in PacRunner, which
> has a dæmon which sits on DBus and answers questions. Its
> "libproxy.so.1" replacement is just a trivial DBus client, and that's a
> much better way of doing things. I'll be putting in a review request for
> pacrunner shortly.
This approach is much better for Linux, but it doesn't work on other
platforms. And libproxy is widely used precisely because it is
multi-platform. I'd like to retain this (even if we retain none of the
original code). In general however, I don't want us to have multiple
choices between incomplete implementations. Let's either fix libproxy or
make something like pacrunner multiplatform.
> In the meantime, though, there's nothing to stop us continuing the
> process of fixing all applications and http libraries to use libproxy.so
> by default. We've done some, and there's more to be done. I'm half
> tempted to submit it as a Feature for F20.
> Is anyone else interested in getting this fixed?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel