apt/aptitude need to take global proxy settings into account

[Marko Poutiainen]

Binary package hint: sudo

sudo version 1.7.2p1 in Ubuntu Lucid Beta 1 does not keep the http_proxy variable any more. So "sudo aptitude update" doesn't work in my work environment any more after update from Karmic.

[csantiago (santiago-carlos)]

it also affects me. I circumvent it using:

1) sudo sh
2) apt-get install ...

See example in https://bugs.launchpad.net/ubuntu/+source/wget/+bug/554068, that is a but related to wget

[csantiago (santiago-carlos)]

Related post in https://bugs.launchpad.net/ubuntu/+source/wget/+bug/554068 (by humble_coffee)

««
I am also having issues with wget behind a proxy. Trying to download any address that requires proxy authorization fails with the following message:

"failed: Connection timed out."

Also it seems to be trying to connect using port 80. Shouldn't it be using the port specified in the proxy setting? I have the proxy configured correctly in the Gnome Network Proxy Preferences and everything else that needs proxy access works fine, with the exception of apt-get. It's error message is:

"407 Proxy Authentication Required"
»»

[Arvind (arvind0)]

It's not just apt-get. I have noticed the same issue with wget.

wget works fine through the proxy when run as user and as root (through sudo -s)

However sudo wget ___ fails to use the proxy settings.
The same settings work fine in 9.10

[Mark Appier (appier)]

I am getting the following error message:

W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/lucid-updates/multiverse/source/Sources.gz 407 Proxy Authentication Required

This is after attempting to set the proxy via:

$ export http_proxy="username:<email address hidden>:port"

This setting has worked in previous releases from 8.04 to 9.10

[Peter Hagen (peter-willowmedia)]

In the final release of 10.04, after using sudo, the http_proxy setting is gone. The proxy setting has been set with the 'system wide' option. In a shell of a normal user, its visible:

>export
declare -x http_proxy="http://192.168.???.???:8080/"
declare -x https_proxy="https://192.168.???.???:8080/"
declare -x no_proxy="localhost,127.0.0.0/8,*.local,"

but, after a sudo -s, its gone:

>sudo -s
# export
... (no http_proxy)

the right information about the settings can be found in the /etc/enviroment file. I guess the sudo command doesn't look at this file, or it doesn't take the settings from the current user with it. This is why 'sudo wget...' and also the 'sudo apt-get install flash...' doesn't work. After sudo -s, add the proxy settings with: export http_proxy="http://192.168.???.???:8080", and then 'apt-get install...' it works flowless

[markusheinzer (markus-heinzer)]

This is a serious bug since installation of packages works only over synaptic anymore. Neither "sudo apt-get install package" nor "apt://package" work anymore. Thanks for caring about this.

[FP (fabrice-pardo)]

Not sure that's a bug. In hardy, "man sudo" said nothong about the fact that sudo keeps http_proxy
environment variable.

My workaround is the alias
  alias sudop='sudo http_proxy=$http_proxy'
with simple quotes!

[Peter Hagen (peter-willowmedia)]

In a production server with ubuntu 7.04, a sudo -s and export returns the setting of the user which gave the sudo command. This looks like normal behaviour to me. On 10.04 when I'm a normal user, and do a:

sudo echo $http_proxy

I get my proxy settings. While doing the sudo -s and export, its empty, even though the proxy is set as system wide. So, I do think its a bug. Maybe not because of the system wide info, but because of the proxy settings from the current user how executes the sudo command.

Im sure that in former versions this was working, and for system administrators I can't imagine this is wanted behaviour. Why do you else set the system wide proxy settings?

[Peter Hagen (peter-willowmedia)]

ow, as extra information, the following will also not work:

sudo -s
export http_proxy=http://???.???.???.???:8080
sudo wget http://whatever.url.something

Wont work also. Im sure this shouldn't be the wanted behaviour?

For your alias solution, I'm sure it will work, but I think this should work out of the box. Its the same issue for the apt-get problem reported in another bug. And maybe even more bugs, but not sure about that.

[Muelli (ubuntu-bugs-auftrags-killer)]

probably pretty much bug 207768. A workaround is described there in bug 207768 comment #4:
Add smth like Defaults env_keep="no_proxy http_proxy XAUTHORIZATION XAUTHORITY TZ PS2 PS1 PATH MAIL LS_COLORS KRB5CCNAME HOSTNAME HOME DISPLAY COLORS" to your /etc/sudoers.

[Florian Schröck (mael-reverted)]

workaround for apt/apt-get: put this line into /etc/apt/apt.conf

Acquire::http::Proxy "http://hostname:port/";

[Dan Halbert (dhalbert)]

The symptoms described are due to changes made for bug 432631. Perhaps this should be marked as a duplicate (though it's kind of an anti-duplicate!)

The documentation of this change is in /usr/share/doc/sudo/changelog.Debian.gz:

sudo (1.7.2p1-1ubuntu4) lucid; urgency=low

  * env.c: Revert addition of "http_proxy" again. This was an Ubuntu specific
    EBW hack, caused inconsistencies with other proxy variables (such as
    https_proxy and ftp_proxy), made sudo incompatible to upstream
    behaviour/documentation. This is solved in a much better way in apt itself
    and gnome-network-properties now. (LP: #432631)

[changes in intervening versions elided]

 -- Martin Pitt <<email address hidden> (1.7.0-1ubuntu1) karmic; urgency=low

[...]
   - env.c: Add "http_proxy" to initial_keepenv_table, so that it is kept
     for "sudo apt-get ...". (Ubuntu specific EBW hack, should disappear at
     some point)

[Geraldo (geraldoamaral)]

Sudo doesn't preserve "http_proxy" environment variable anymore by default in Ubuntu 10.04. :-(

To see the (hardcoded) list of variable preserved by sudo, use the command:
  sudo -V

Solution: add to "/etc/sudoers" (via sudoers command) the following line:
  Defaults env_keep="http_proxy"

Now, $http_proxy is available to all commands run via sudo, check it using:
  sudo env | grep proxy

Nonetheless, I think http_proxy should be in that hardcoded list.

[Wolverine (nareshtechs)]

This is very annoying. I have modified cntlm proxy to work with basic auth. And everything was working fine till this bug appeared. I do no su ever. So exporting my variables with sudo worked okay. And when I tried to do an apt-get it just failed to resolve the host names. I started debugging my local proxy when I realized that apt-get does not send any requests to it at all.

Why in the name of )==() does this pass through unnoticed? If the solution is as simple as Geraldo comments, I suggest it is released in a patch pretty soon. Atleast all the proxy environment variables should be saved.

My work around for the solution was to explicitly add a proxy line in apt.conf. But now I need to remove it everytime I get out from behind the proxy and start using direct connections.

Hope this gets fixed soon.

[Wolverine (nareshtechs)]

Confirmed bug.

[Stanislav German-Evtushenko (giner)]

Here are two work arounds that I use:

1) adding to /etc/sudoers:
Defaults env_keep = "http_proxy https_proxy ftp_proxy"
or
2) sudo -E apt-get install ...

Hope this gets fixed soon too.

[Olzhas Adiyatov (olzhas)]

one more solution is

# sudo -i aptitude install ...

[jehon (jeanhonlet)]

Since in the main (ubuntu) menu System > Network Proxy, you have an "apply system wide", this "http_proxy" variable should be taken care of somehow...

Either
a/ by passing it through sudo
b/ the menu configuration add it somewhere somehow so that sudo get initialized with the "global official variable" (if a sudo.initial_env file would have existed, should be placed there).

solution b is more security-proof.

[Martin Pitt (pitti)]

sudo is the wrong place to fix this, I'm afraid. What should happen instead is that apt itself should use the global proxy settings, either directly from /etc/environment, or indirectly by changing ubuntu-system-service to additionally write an apt configuration file with the proxy settings. Michael, do you have thoughts on this?

[Micah Cowan (micahcowan)]

I strongly disagree with that idea. Reading from /etc/environment means that user-specific proxy settings are lost.

Not letting apt receive the environment properly from its parent also means that you can't set up a temporary environment where all web fetches ought to go through a proxy, when you don't want fetches from other shell sessions going there.

Having apt get its environment like every normal program does seems important, to me, and doing so would seem to necessitate sudo allowing http_proxy through.

On the other hand, perhaps it's not a terrific idea to always allow http_proxy through, in case the user is unaware that it was set out from under him (potential security problem?). Is that the reason you're reluctant to alter /etc/sudoers for this?

[Mike Pontillo (mpontillo)]

I can tell you that as a user of Ubuntu systems behind firewalls (where the only way to get out is an HTTP proxy), I would *always* want http_proxy to be passed through. Otherwise, if I want to run something that connects via http to the Internet, I have to do:

$ sudo -i
Password:
# export http_proxy=http://myproxy:8080/
# <command>

That's a lot of typing for every command, and it tempts me to just leave a root shell open instead of using 'sudo'.

It is important to note that if http_proxy is allowed through, no_proxy should also be allowed through. Otherwise, if I have a mix of internal and external .deb sources, apt-get still won't work. For an example, see:

http://serverfault.com/questions/42426

I suppose this implies that ftp_proxy should also pass through, for a complete solution.

[Taylor Braun-Jones (nocnokneo)]

I agree with Mike. I assume sudo takes the whitelist approach to environment variables for security purposes (versus passing everything through and only blacklisting some), but that means the the default whitelist should be actively maintained so that that the most common use case scenarios work out of the box.

[Keith Rumley (keithrumley)]

I also agree with Mike. I'm constrained to specific proxies here at work.

My pain point being 'sudo wget' during 'make' scripts.
(Used workarounds from comment #16 successfully)

[dxjia (dxjia)]

Just as an update to this issue, it exists as of today on Ubuntu Natty 64bits. As noted above, the following circumvent it.

1) sudo sh
2) apt-get install ...

[Taylor Braun-Jones (nocnokneo)]

There is a simpler workaround to preserve the http_proxy environment variable:

sudo -E apt-get install ...

However this preserves all other (potentially dangerous) environment variables. The point is that that environment variables which are safe and commonly needed in a sudo environment should be whitelisted by default.

[Oliver Dungey (oliver-dungey)]

Taylor - I know that is a valid solution for many situations but it is not really a workaround, that is using the wrong users environment settings.

I have been working for 3 years with the Amazon Cloud from inside a big corporate and I am sick to the back teeth of these proxy issues that have been floating around for years. For every one that gets fixed another creeps in.

I suspect the entire approach to proxy configuration is wrong: it needs to be invisible to the applications, they should not require additional code to support proxy servers when the whole thing can be transparent. I think the best solution would be to run a lightweight forwarding-only transparent proxy server locally.

[Martin Pitt (pitti)]

Note that for many releases now the proxy configuration guy (through ubuntu-system-service) is supposed to set the proxy in both the environment and the apt configuration. It will also ask you whether you want to apply a proxy configuration system-wide if you try to change it for your user only. Is that working, or broken?

I reiterate that sudo is the wrong place to fix this. These days software-center, apt-daemon, etc. don't use sudo, so having this hack there wouldn't actually help to make the package installers see the proxy. This really needs to be solved by respecting the proxy settings in /etc/environment.

[Barry Warsaw (barry)]

Given Martin's comment in #29, and the -E or /etc/sudoers solutions, is there really anything to do in apt? I don't think you want apt to get the proxy from ubuntu-system-services (although maybe it makes sense to do so optionally if the service can be contacted).

[Brian Murray (brian-murray)]

To be clear ubuntu-system-services sets the proxy server for you in /etc/apt/apt.conf:

root@flash:/etc/apt# cat apt.conf
APT::Authentication::TrustCDROM "true";
Acquire::http::proxy "http://192.68.10.1:3128/";
Acquire::https::proxy "https://192.68.10.1:3128/";
Acquire::ftp::proxy "ftp://192.68.10.1:3128/";
Acquire::socks::proxy "socks://192.68.10.1:3128/";

[Steve Langasek (vorlon)]

If ubuntu-system-services is setting the proxy information in apt's config already, I don't think there's actually anything more to be done here. We should definitely *not* be whitelisting the http_proxy variable for sudo, as this allows a user with restricted sudo access to mitm attack http traffic to a program running as root. While this is presumably not a security risk for the many users on this bug report who administer their own machines, the sudo config we ship must remain secure across all the various install scenarios we support. Consequently, I agree with Martin that we should not be implementing this by letting sudo pass http_proxy by default, and we appear to already handle global proxy configuration via ubuntu-system-services.