Regression: "Automatic proxy configuration" + gnome-terminal now breaks apt-get, curl, wget...

Bug #433827 reported by Nathaniel Smith on 2009-09-21
66
This bug affects 10 people
Affects Status Importance Assigned to Milestone
libsoup
Fix Released
Medium
apt (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok
curl (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok
gnome-terminal (Ubuntu)
Low
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok
libsoup2.4 (Ubuntu)
Low
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok
update-manager (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok
wget (Ubuntu)
Undecided
Unassigned
Nominated for Karmic by Anthony Fok
Nominated for Lucid by Anthony Fok

Bug Description

Binary package hint: gnome-terminal

The fix for bug 48294 -- at least as implemented in gnome-terminal 2.27.92-0ubuntu1 from Karmic -- may be theoretically more correct, but it seems to have broken strictly more apps than it fixes.

Steps to reproduce:
1) Go to System -> Preferences -> Network Proxy, select "Automatic proxy configuration", and enter the URL of a PAC proxy (I use http://webproxy.ucsd.edu/proxy.pl).
2) Start a gnome-terminal.
3) echo $http_proxy

Before bug 48294 was fixed, this produced "http://:8080", which breaks wget, but most apps are happy to ignore it this obviously invalid URL. One can reproduce the old behavior easily at the command line:

$ http_proxy=http://:8080 wget google.com # FAILS: "Error parsing proxy URL"
$ http_proxy=http://:8080 curl google.com # SUCCEEDS
$ http_proxy=http://:8080 sudo apt-get update # SUCCEEDS

With current gnome-terminal, the above steps result in http_proxy being set to "pac+http://webproxy.ucsd.edu/proxy.pl". I cannot find any reference to this "pac+http" URL scheme anywhere, and indeed, apps do not know how to handle it:

$ http_proxy=pac+http://webproxy.ucsd.edu/proxy.pl wget google.com # FAILS: "Error parsing proxy URL"
$ http_proxy=pac+http://webproxy.ucsd.edu/proxy.pl curl google.com # FAILS: "couldn't connect"
$ http_proxy=pac+http://webproxy.ucsd.edu/proxy.pl sudo apt-get update # FAILS: 404 errors

So not only did this "fix" fail to fix the old broken software, it breaks new software, and the newly broken software is failing in very confusing ways.

In the long run this should perhaps be considered a bug in wget, curl, apt-get, and every other HTTP implementation in in Ubuntu, but I'm filing against gnome-terminal because 1) that's what caused the regression, 2) at this point in the release cycle I'm guessing you might want to just unset http_proxy in these proxy auto-config cases (none of this software could parse the PAC file anyway, it requires a javascript interpreter), rather than try to fix everything everywhere...

Nathaniel Smith (njs) wrote :

Actually, I'm sorry, it might not be gnome-terminal that has the offending code anymore -- this bug seems to affect apps launched from the panel, too.

In particular, update-manager is now broken. (I was *wondering* why it hadn't popped up since I upgraded...) The error message is uninformative, but I confirmed that it is the same problem by (1) verifying via /proc/$(pidof update-manager)/environ that update-manager had the bad http_proxy variable set, (2) turning off the proxy in Network Proxy Preferences, (3) restarting update-manager (4) confirming that the http_proxy environment variable was gone and that (5) update-manager now worked.

I think that may make this what Debian would call a "critical" bug.

Changed in gnome-terminal (Ubuntu):
importance: Undecided → Low
Nathaniel Smith (njs) wrote :

...A bug that is deterministically reproducible and prevents everyone affected from installing or upgrading any packages whatsoever, with no useful error message, is importance "Low"?

I'm sorry -- I don't want to be one of those hysterical bug commenters. I just do want to make sure that I've been clear about the actual impact of this bug.

AFAICT, users with an auto-configured proxy (e.g., most university users with a library proxy, various corporate users, etc.) simply *cannot install* upgrades, bug fixes, security fixes, etc., without a manual workaround. 'apt-get' doesn't work. Update manager doesn't work. Once someone is affected by this bug, they will not receive whatever fix is eventually released. The longer it persists, the more users will get "stuck" like this.

Also, as noted above, it isn't actually a bug in gnome-terminal, but in whatever program is responsible for setting up the environment for panel-launched programs. gnome-session? gnome-panel? I'm not sure.

Gordon Hopper (gohopper) wrote :

The automatic proxy configuration breaks apt, etc. I think this is a bug with the environment; not a bug with apt. Does that mean a bug in gnome-settings-daemon? I don't know.

For what applications does setting "http_proxy=pac+http..." work correctly?

gnome-terminal 2.28.0-0ubuntu1

Alkis Georgopoulos (alkisg) wrote :

I think that the "pac+" scheme is added by libproxy0:

From libproxy/src/plugins/gnome.c:
 // Mode is wpad:// or pac+http://...
 else if (!strcmp(mode, "auto"))
 {
  char *tmp = gconf_client_get_string(client, "/system/proxy/autoconfig_url", NULL);
  if (px_url_is_valid(tmp))
   url = g_strdup_printf("pac+%s", tmp);
  else
   url = px_strdup("wpad://");
  px_free(tmp);
 }

I don't know if it is libproxy0 that exports that value to the environment without removing the pac scheme though, or some gnome component.
I also don't know if keeping the "pac+" scheme is the right thing to do or not... But it might be a good idea to notify the libproxy0 developers to see this bug report.

Nathaniel McCallum (nathaniel) wrote :

This is unrelated to libproxy, since the "pac+" is an internal implementation detail and is never exported to the environment or otherwise exposed via the API.

Alkis Georgopoulos (alkisg) wrote :

Nathaniel thanks again for your input, and sorry for bothering you with this.

I located the component that inserts that "pac+": it's libsoup-gnome2.4-1.

1) I ran `apt-get source libsoup-gnome2.4-1`

2) I modified "pac+" to "pac+debug" in libsoup/soup-proxy-resolver-gnome.c:
 } else if (proxy_mode == SOUP_PROXY_RESOLVER_GNOME_MODE_AUTO) {
  char *autoconfig_url;

  autoconfig_url = gconf_client_get_string (
   gconf_client, SOUP_GCONF_PROXY_AUTOCONFIG_URL, NULL);
  if (autoconfig_url && !strncmp (autoconfig_url, "http", 4))
   http_proxy = g_strconcat ("pac+debug-", autoconfig_url, NULL);

3) I compiled and installed this modified libsoup, and rebooted my PC.

4) echo $http_proxy now showed: pac+debug-http://server

So this is where the "pac+" that we see originates.

Again, I don't know if libsoup is correct in adding that "pac+" there or not. I'm just proposing that we notify the libsoup developers about this bug, so that we have their opinion on the subject.

Alkis Georgopoulos (alkisg) wrote :
Changed in libsoup2.4 (Ubuntu):
status: New → Triaged
importance: Undecided → Low
Przemek K. (azrael) wrote :

Same bug in msttcorefonts: Bug #274421 (triggers very often, lots of duplicates)

Another similar bug in b43-fwcutter: bug 326752
Error parsing proxy URL http://:8080/: Invalid host name.

Przemek K. (azrael) wrote :

Can we also patch wget to ignore the invalid http://:8080 proxy url?

Fail2Ban (failtoban) on 2010-02-20
Changed in gnome-terminal (Ubuntu):
status: New → Confirmed
Changed in libsoup:
status: Unknown → Fix Released
Changed in libsoup:
importance: Unknown → Medium
Huygens (huygens-25) wrote :

I don't know if my problem is similar or not, but here are the details:

I'm using Ubuntu 10.04 LTS with latest updates.

At work, we use a proxy and we have an automatic script for that. This is handy so when I'm home, it does not find the script and no proxy is configured which is what I want.

Anyway, I performed the above steps described in this bug report: configuration automatic proxy, applying it system wide, launching gnome-terminal and echoing $http_proxy or even $HTTP_PROXY.
The result is that none of the env variables are defined!

So many applications are broken: weather applet, wget, Update Manager, Ubuntu Software Centre, Eclipse, etc. actually it's easier to give the list of application working with this: Firefox and Chromium.

So this bug is critical in my opinion! Or maybe the new bug that I would need to open if it is not directly related. ;-)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apt (Ubuntu):
status: New → Confirmed
Changed in curl (Ubuntu):
status: New → Confirmed
Changed in update-manager-core (Ubuntu):
status: New → Confirmed
Changed in wget (Ubuntu):
status: New → Confirmed

Is any of the affected users still seeing this bug with the latest versions?

affects: update-manager-core (Ubuntu) → update-manager (Ubuntu)
Changed in libsoup2.4 (Ubuntu):
status: Triaged → Fix Released
Changed in curl (Ubuntu):
status: Confirmed → Incomplete
Changed in apt (Ubuntu):
status: Confirmed → Incomplete
Changed in gnome-terminal (Ubuntu):
status: Confirmed → Incomplete
Changed in update-manager (Ubuntu):
status: Confirmed → Incomplete
Changed in wget (Ubuntu):
status: Confirmed → Incomplete

Closing for all other packages at it is fixed released in libsoup

Changed in apt (Ubuntu):
status: Incomplete → Invalid
Changed in curl (Ubuntu):
status: Incomplete → Invalid
Changed in gnome-terminal (Ubuntu):
status: Incomplete → Invalid
Changed in update-manager (Ubuntu):
status: Incomplete → Invalid
Changed in wget (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.