Setting the network proxy doesn't change the synaptic proxy settings (gnome-network-preferences) for authenticated proxies

Bug #300271 reported by dirken on 2008-11-20
This bug affects 11 people
Affects Status Importance Assigned to Milestone

Bug Description

When changing the proxy (gnome-network-preferences) to a manually defined http proxy the changes do not affect Synaptic even not when pressing the "apply system-wide..." button.

UPDATE: It seems that the proxy is set but not the required password and username!

dirken (dirkvranckaert) on 2008-11-20
description: updated
RickB (rick-777) wrote :

When the "Apply system-wide..." button is pressed, changes are written to /etc/environment. However, this file is written incorrectly because the username/password is omitted. Also there is no no_proxy setting for the ignored hosts.

This is easy to observe. Change the gnome-network-preferences. Press "Apply system-wide". Open a terminal and

set | grep proxy; cat /etc/environment

to observe the differences.

TRiSS (triss) wrote :

I can confirm this: no password or no_proxy variables are written to /etc/environment.

This probably means this bug affects all 'terminal' apps, since they would all need the passwd and no proxy infor;ation to function correctly...

dirken (dirkvranckaert) wrote :

Isn't it just possible to use the gnome settings 'cause they work fine!

TRiSS (triss) wrote :

If you are referring to gnome-network-preferences, that's what I used to set the proxy and proxy exceptions settings. This is supposed to write some variables which other programs use (amongst which, I suppose, synaptic, but also things like wget), in /etc/environment.

When you change the settings using gnome-network-preferences (and use the set system wide button), some variables are not written to /etc/environment, namely the ones that govern the authentication for the proxy, and the exceptions list. The ones that say which server to use are written to that file. This has the effect that an effected app either can access the proxy server but can't authenticate, or that it can access a proxy server that doesn't use authentication, but doesn't know when NOT to use the proxy, eg when accessing stuff on the local LAN.

Steps to reproduce:
1) open gnome-network-preferences
2) select manual configuration, enter a valid proxy server, set up authentication if needed
3) add some exceptions on the next tab
4) click set system wide, fill in password
5) check /etc/environment: observe that the settings for the proxy are there, except the ones for authentication, and the no_proxy one.

David Birch (david-birch) wrote :

   i use proxy settings daily & resorted to dispatcher scripts (from here as using apply globally doesn't revoke proxy settings properly - /etc/environment & /etc/apt/apt.conf don't have proxy settings changed when it is changed back to no proxy.

any good fixes much appreciated


me too - bump

This get's me twice every day when I change between my work and home networks

S. D. (akjag) wrote :

My path to this bug:

1) System->Preferences->Network Proxy
2) Manual Proxy Configuration
3) Set up authenticated proxy for all protocols
4) Ignore some hosts
5) Apply System-Wide...

Contents of "/etc/environment" then only contain http_proxy="".

Should be something like:


Lame bug!! Please do fix for us :-)

(NOTE... don't mind disclosing that proxy IP, it's a non-routable address anyway, at work to boot! So, please no comments about that)

S. D. (akjag) wrote :

Wow... peeking at dupes, it seems that authentication and non-proxy host lists have been broken for years!!

Authenticated proxy is a very common requirement at large companies (I work for a multi-national audio equipment manufacturer with ~10,000 employees, or so, worldwide for example), especially for filtering content. I won't say the name of the filtering software/server solution because I don't want to give them any free advertising or kudos :-)

Anyway... this is going to manifest itself in lots of ways outside of synaptic, and probably result in a LOT of weird duplicates on other applications. Worse, many apps (grip, picard, firefox, pidgin, etc...) have their OWN proxy settings, so what happens is that the user ends up configuring twenty different apps with their proxy authentication information (which, by the way, is usually your corporate desktop user & password!! so, yeah, fairly significant security worry there, too) instead of the global proxy environment variable. Not that an environment variable with a password in plain-text is better security, but at least it's only in one place...

I'll stop rambling now. My point is that this bug may be somewhat bigger than it looks, and frustrate people in unexpected ways, be aware.

description: updated
RickB (rick-777) wrote :

That's a good description - I had been thinking along the same lines. This is not just an implementation bug - it needs broader thinking to produce a joined-up solution.

As far as security is concerned, /etc/environment and /etc/apt/apt.conf open a BIG can of worms.

Changed in debian:
status: Unknown → New
Changed in gnome-control-center:
importance: Unknown → Medium
aaron (nelaaro) wrote :

Ubuntu 10.04 lucid

I don't think this is just a duplicate. I think there are issues with both sudo and network preferences.

I checked my gnome gconf


It is not updating proxy setting correctly. I have two location set in the Network proxy preferences. Home and work
it does not change those setting when click apply system wide while changing location. I have added some ignore hosts
for both my home and work settings, but different host are ignored at home and work. It does not update these correctly in.


also /etc/environment is not changed and dose not have a no_proxy option added. Which is probably a duplicate of of bug

aaron (nelaaro) wrote :

I understand how gconf was working now. It would clear the setting out every time I was looking at a particular location in the Network Proxy Preferences Widget. I am sorry It does work correctly. As it should. Sorry again for opening this bug.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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