Created attachment 183076 [details] [review]
libproxy: add a PAC/WPAD handling D-Bus service

libproxy can deal with PAC and WPAD; other proxy resolvers may not be
able to, so let them use libproxy to do it.

Having it out-of-process is good because the only way to force
libproxy to do exactly what we want is to fiddle with environment
variables, and we don't want those to leak into the environment.

Created attachment 183077 [details] [review]
Implement a GNOME proxy backend using GSettings

Use the network proxy settings from gsettings-desktop-schemas and
return proxies based on that.

For Automatic proxy configuration, we use the D-Bus service provided
by the libproxy plugin.

I've tested that the dbus service does at least talk to libproxy. But F15 apparently is no longer shipping either libproxy-webkit or libproxy-mozjs, so you can't actually get working autoconfiguration. (I discovered this *after* writing all the code of course.) I emailed the fedora libproxy maintainer to figure out what's up with that.

The gnome plugin has a higher priority than the libproxy plugin, so if you have both installed, the gnome network control panel settings will have precedence over anything libproxy might do.

Created attachment 183079 [details] [review]
Implement a GNOME proxy backend using GSettings

oops. realized as i was writing the last comment that I hadn't actually
tested the gnome-plugin-to-dbus-service part yet. fixed.

+  if (resolver->ignore_hosts)
+    g_strfreev (resolver->ignore_hosts);

Minor nitpick: g_strfreev is NULL-safe.

We should just get this in, I think. Code freeze looms.

Attachment 183076 [details] pushed as eaaa73e - libproxy: add a PAC/WPAD handling D-Bus service
Attachment 183079 [details] pushed as 00c639c - Implement a GNOME proxy backend using GSettings

I think we need a bit of a rethink about how proxy configuration works.

Fundamentally, a proxy is a per-connection thing. It's a function of how you are connected to the Internet.

The proxy that you use for a given connection can be detected by various means: 
 - a VPN server may set it for the VPN connection.
 - a DHCP server may set it for a given connection.
 - It may be automatically discovered by the 'wpad.$searchdomain' DNS trick.

All of these things really live in NetworkManager.

And even when the user configures it manually, it is still a *PER-CONNECTION* thing. It shouldn't be a single global setting in GSettings; it still lives in the NetworkManager settings for each *individual* connection.


Having discovered the proxy which should be used with the system's current connection, we then want a *single* process to load the PAC file into a javascript interpreter and serve requests. We don't want the whole JS interpreter being loaded into every client, as in the libproxy model.

There exists a simple standalone dæmon which will do this; the 'pacrunner' dæmon used in MeeGo. There it's used with ConnMan, but it's not at all tied to ConnMan and would work just as well with NetworkManager.

We should use it, rather than reinventing our own.

(In reply to comment #8)
> I think we need a bit of a rethink about how proxy configuration works.

yes, this is known, and there was discussion of fixing this during the gsettings migration, but no one did.

> Fundamentally, a proxy is a per-connection thing. It's a function of how you
> are connected to the Internet.

That's the "normal end user" model, but there's also the power-user "please filter everything through privoxy/wwwoffle" model.

> We should use it, rather than reinventing our own.

Too late. As of glib-networking 2.28.4, there is a pac-running D-Bus service (which currently uses libproxy). It is used by the "gnome" (ie, gsettings) proxy resolver, to avoid the issues with needing to munge the environment to get libproxy to do what we want, though it also has the nice "don't load JS interpreter into everything" side effect.