See also bug 740917.

I can't see this being a security hole. After all, you do specify the proxy settings. You tricking your own software to behave differently/incorrectly is not a security issue.

That being said, I tend to agree with your request, the terminal emulator is not the best place to set these variables. It should probably happen "outside" of it (bug 740917 comment 3 – but then it's even harder to change it run-time), or maybe "inside" (via bashrc or similar – but then it's problematic if you start the app right away in the terminal without shell). Not sure what the best solution would be.

(In reply to Christoph Anton Mitterer from comment #0)

> gnome-terminal is, as the name says, at terminal emulator,

vte emulates xterm, gnome-terminal is GNOME's terminal application.

> and IMHO it's not
> the domain of a terminal emulator to set any environment variables which are
> not related to the terminal (e.g. TERM, COLUMNS, ROWS and that like).

In the past when I had to use a proxy to access the Internet, I found it quite convenient to have these variables set for me if I had already configured the proxy in Settings. Most people don't want to use a different networking setup for each application.

> 1) Since these are not GNOME-specific variables it affects other
> applications as well, which is IMHO already fundamentally wrong.
> GNOME should really not try to "force" its "goodness" upon other non-GNOME
> applications like mplayer, wget, and so on.
> These have their own ways to configure proxies and I do no want GNOME to
> automagically decide that for me (especially as it's buggy).

I don't understand. If they had their own ways to configure proxies then they wouldn't have been reading these variables.

> 2) Since GNOME's policy is typically to remove features

You know, people would take you more seriously if you didn't throw in a few gems like these.

> one cannot set
> the proxy in most GNOME apps, but has to do it at the system-wide settings.
> So if I just want to use a proxy in e.g. evolution to access some special
> network, or epiphany to use tor,.. I have to do it globally and thus
> gnome-terminal will set it in all shells started thereafter and all programs
> using the above general variables will try to use these proxy settings.

Basically what you are asking for is a way to have application specific network settings.

Can't you unset these variables in your .bashrc or .bash_profile for the time being? You already have quite a specialized networking setup, so I can't imagine it being a lot of trouble to unset a few variables.

Well it's of course not a security hole in the sense of "immediate root access" or something like that.
But as I've said, it may cause software that is security sensitive to not work correctly (with no one noticing, since no one expects a proxy is set automagically), it may cause data leakage (like when you have configured an internal proxy i.e. "my.secret.interanet.proxy.example.org" and so on... also small issues like this can be the linchpin of an attack.

Especially concerning is IMHO that the proxy settings may be easily forwarded to remote hosts, e.g. when SSHing.


I don't think there is a "right" solution (apart from simply not doing it),... even when you abuse things like bash's prompt command, some (or even all?) of the issues I describe still persist.
And it would be non portable.

As I said, programs that want to use the GNOME proxy settings should use the respective lib/API/interface/whatever.
Setting this in the environment is simply a bad hack,... and it should at best be left in place as an opt-in functionality (i.e. for people that know what they do and/or whose proxy settings never change, work with everything, etc.


Cheers,
Chris.

(In reply to Debarshi Ray from comment #2)
> vte emulates xterm, gnome-terminal is GNOME's terminal application.
Yes,... I didn't claim the opposite, did I?


> In the past when I had to use a proxy to access the Internet, I found it
> quite convenient to have these variables set for me if I had already
> configured the proxy in Settings. Most people don't want to use a different
> networking setup for each application.
As I said, it *may be convenient* for some people, but as I pointed out above it also has all kinds of flaws.
I'm happy if you leave the feature in, but then a) please make it configurable and b) it shouldn't be the default (because not all people read the code and or try everything out just to discover such unexpectable behaviour)

 
> I don't understand. If they had their own ways to configure proxies then
> they wouldn't have been reading these variables.
Sure they have, but if they also read these env vars, then they will pick up any set values.
But these env vars are generic and where never meant to be set by the desktop environment (especially not silently automatically), but rather manually by the user.


> > 2) Since GNOME's policy is typically to remove features
> You know, people would take you more seriously if you didn't throw in a few
> gems like these.
Well as a matter of fact, this is often the case, isn't it? Some people like it some not. My comment here was not necessarily meant to condemn this philosophy (even though I personally don't like it), but rather to describe the motivation that followed, why I had to set the global proxy values at all (instead of e.g. just setting the Evolution proxy).

So no need to feel offended =)

 
> Basically what you are asking for is a way to have application specific
> network settings.
No, at least not in the ticket ;-) ... I'm fine with GNOME setting one global proxy for everything, but then please only for GNOME programs, respectively those which explicitly use GNOME's lib/API/etc. to discover these settings and hopefully document their behaviour properly.

 
> Can't you unset these variables in your .bashrc or .bash_profile for the
> time being? You already have quite a specialized networking setup, so I
> can't imagine it being a lot of trouble to unset a few variables.
I can do this *for now* and *as a workaround* but people shouldn't need to fix a feature which is conceptually simply more a hack than really good.
Also, no one else who may be surprisingly hit by these issues would take notice of me unsetting these vars ;-)

And as Egmont already pointed out, there is another ticket, where someone asks for actually adding more such vars - and I really don't want having to check every new gnome-terminal and/or VTE release when and under which possible cirscumstances some possibly harmful variables are set or not.

Apart from that it would require to fix this in n possible shells that may run on our systems... plus I'm not even sure whether really all cases can be caught, taking e.g. bash as example, there are several cases of invoking bash, where neither .bashrc/et cetera nor .profile/et cetera are loaded.

Best wishes,
Chris.

(In reply to Christoph Anton Mitterer from comment #4)

> But these env vars are generic and where never meant to be set by the
> desktop environment (especially not silently automatically), but rather
> manually by the user.

(s/where/were I assume)

> No, at least not in the ticket ;-) ... I'm fine with GNOME setting one
> global proxy for everything, but then please only for GNOME programs,
> respectively those which explicitly use GNOME's lib/API/etc. to discover
> these settings and hopefully document their behaviour properly.

So, following this philosophy, if I alter the language, keyboard layout, timezone etc. in my Gnome settings, it should only effect Gnome applications? No, thanks!

It's not about settings vs. not setting an environment variable – that's a pure technical details. It's about requiring to set a certain thing at 1 place only, or separately for each app. Requiring different proxy settings for different utilities is a very special rare use case. Most people want to set it at 1 place only and have it working in every app. That's what users should receive by default. Whether the technical implementation requires an env variable or other technique is a minor detail in this picture. There's definitely room for improvement in the implementation of this detail, but I firmly believe that the overall picture, the goal should remain the same.

(Merging with the other thread – In reply to Christoph Anton Mitterer from bug #740917 comment #7)

> Apart from that, I think this is simply basic security ABC... just take a
> look at any sane program from the security area, they either strongly warn
> against using passwords in env vars, or intentionally don't implement
> something like that at all (e.g. gpg).

References, please?

Note that introducing the http_proxy variable wasn't Gnome's idea.  It was a common practice probably before gnome-terminal or maybe even Gnome development started.  You might argue that it's broken by design, but that's what we have to live with.

> And since no one can expect that gnome-terminal/vte sets any sensitive data
> in env vars, why should one not do if it seems handy.

This is the big difference between us.  You think in terms of environment variables: bits here and there, a bottom-up approach and you freak out when we change a bit without warning you about it.  I (and apparently Debarshi too), on the other hand, think about the overall user experience: we just want to make this work out of the box in as many apps as reasonably possible, whatever the necessary technical bits are.

I have a feeling that you would equally dislike any other approaches I outlined in comment 1, since they're all about settings these variables somewhere else other than gnome-terminal, whereas you argue for not setting these variables at all – do I see it correctly?  I'm quite certain that this is not going to happen.

cheers,
egmont

(In reply to Egmont Koblinger from comment #5)
> (In reply to Christoph Anton Mitterer from comment #4)
> > But these env vars are generic and where never meant to be set by the
> (s/where/were I assume)
Yes,... sorry... it's late ^^


> So, following this philosophy, if I alter the language, keyboard layout,
> timezone etc. in my Gnome settings, it should only effect Gnome
> applications? No, thanks!
I don't think that you can apply that argument.
The main questions are:
- is a certain behaviour expected
- is it directly visible

As for the language (at least in terms of C locale), keyboard layout, timezone, etc. ... these are not GNOME specific things. They're typically not even program specific (unless e.g. you manually override the locale/timezone with special magic per program).
- The language is a common setting from C/POSIX locales, and not a GNOME specific thing.
- They keyboard is a X/Wayland specific thing
- The timezone is again a libc thing.

The normal and expected behaviour is:
- one  keyboard layout for the whole (X) system, no one expects, that you'd have qwertz in gedit, but qwerty in vi
- the same for the others
- or the same would apply for e.g. the monitor resolution... it's absolutely clear to everyone that when you change the monitor resolution in GNOME while this is the running DE, then it will affect also all non-GNOME programs


But for proxy servers there isn't such expected global behaviour, especially not, when it has flaws (as shown above) and probably even security implications.

Or similar, if someone changes gnome-terminal to show the scrollbar one wouldn't expect GNOME to automatically create an .Xresources file with the necessary XTerm* settings to display the scrollbar.

But this would at least even be visible, while the proxy thing is not immediately visible, unless it breaks for some reason and one starts to debug.


> It's not about settings vs. not setting an environment variable – that's a
> pure technical details. It's about requiring to set a certain thing at 1
> place only, or separately for each app.
Well I don't think it's appropriate for GNOME (or any other DE) to modify the behaviour of other programs (which didn't opt-in for that).

> Requiring different proxy settings
> for different utilities is a very special rare use case.
Which is a statement that may just apply to your use cases? Actually I've noted that there are many proxies which do not accept all kind of traffic (that's how I took notice of the whole issue)


> Most people want to
> set it at 1 place only and have it working in every app. That's what users
> should receive by default. Whether the technical implementation requires an
> env variable or other technique is a minor detail in this picture.
As I've said before, I'm absolutely happy with it, if 3rd party programs choose to use API xzy, libfoobarbaz or dbus to detect the proxy settings of the running DE (regardless of which).
Then one notices this behaviour if the 3rd party program properly documents it and can chose to disable it if one doesn't like it.

But if a program didn't opt-in to that, it shouldn't be tricked into using the global proxy settings.
IMHO the usage of env vars is actually the critical point here.
I mean just imagine what comes next? Because there are programs which ignore all_proxy/etc. Then GNOME starts collecting the program specific variables like FOOBAR_PROXY and set these as well?


> There's
> definitely room for improvement in the implementation of this detail, but I
> firmly believe that the overall picture, the goal should remain the same.
Then the way should be that GNOME perhaps in conjunction with other DEs should try to convince other projects to use some common API/lib/etc. to determine these settings.

Doing it via the env vars has at least the issues described above, and should therefore not be done.

Apart from that... most pure terminal programs are typically considered to be rather independent from the DE... so I wouldn't want that if I enable/disable the trash bin in GNOME, that it tries to be "smart" and also sets -i / -f on rm.
Some things are simply not meant to integrate into the DE respectively controlled by it.

(In reply to Egmont Koblinger from comment #6)
> References, please?
I already brought gpg as example =) and this is simply kinda common knowledge, I woudln't even know a particular "standard" or that like where it says the obvious.
Storing passwords/etc. in env vars has all kinds of possible issues:
- the problem already mentioned, that it's easily exported to places where it shouldn't
- that people use it in scripts like e.g. "gpg --decrypt --non-existing-password-option "$GPG_KEY_PASSWORD"... completely forgetting that everyone will be able to see it

> Note that introducing the http_proxy variable wasn't Gnome's idea.  It was a
> common practice probably before gnome-terminal or maybe even Gnome
> development started.
I haven't said it was,.. what I said is...

>  You might argue that it's broken by design, but that's
> what we have to live with.
... that it was not meant to be automatically set.
It's rather a convenience option that users can set in their .bashrc so that they don't have to do --proxy foo every time they invoke e.g. wget.
But non of these programs that use it said (or documented): "Oh and btw. we use now http_proxy so that we can get the GNOME/KDE proxy settings."


> This is the big difference between us.  You think in terms of environment
> variables: bits here and there, a bottom-up approach and you freak out when
> we change a bit without warning you about it.  I (and apparently Debarshi
> too), on the other hand, think about the overall user experience: we just
> want to make this work out of the box in as many apps as reasonably
> possible, whatever the necessary technical bits are.
Well as I've said before... sometimes out-of-the-boxness can also got way to far, which is typically then the case when the system reacts in a way that cannot be commonly expected (either by common sense or by long standing practise)... or when it tries to be smart about things were it cannot be really smart. In the end it should still be the user who controls the system and not vice versa.



> I have a feeling that you would equally dislike any other approaches I
> outlined in comment 1, since they're all about settings these variables
> somewhere else other than gnome-terminal, whereas you argue for not setting
> these variables at all – do I see it correctly?
As I've said before, I don't think you can make it work correctly with env vars, simply because you cannot easily alter them once they were set, especially not portable over all shells.
So on the technical level I see no way to make it properly working, unless by using some proper API, as already mentioned several times.

My advise was then, to keep the feature, but make it configurable with defaulting to off, since it breaks things and is apparently a security leak.


> I'm quite certain that this
> is not going to happen.
hmm I'm afraid,... well I'll forward this then Debian, so the the issue might be fixed at least at the distro level.


Cheers,
Chris.

[offtopic]
Christoph Anton Mitterer: About your comment 0 point 2 sentence 1 and comment 4: Please stick to technical discussion of the specific issue in gnome-terminal. 
If you want meta-level discussions about GNOME, use mailing lists, IRC, forums or your blog instead. Repeatedly ignoring can lead to account deactivation. Thanks for your understanding. (And no reply needed as this is offtopic.)

(In reply to Christoph Anton Mitterer from comment #4)
> (In reply to Debarshi Ray from comment #2)
> > vte emulates xterm, gnome-terminal is GNOME's terminal application.
> Yes,... I didn't claim the opposite, did I?

vte being the terminal emulation widget doesn't do any of this. However, it is quite sane for gnome-terminal, being what it is, to expose the desktop-wide settings that you entered to terminal applications.

> > In the past when I had to use a proxy to access the Internet, I found it
> > quite convenient to have these variables set for me if I had already
> > configured the proxy in Settings. Most people don't want to use a different
> > networking setup for each application.
> As I said, it *may be convenient* for some people, but as I pointed out
> above it also has all kinds of flaws.

I will say "most", not "some". Your requirements are clearly not what most people using proxies have.

> > I don't understand. If they had their own ways to configure proxies then
> > they wouldn't have been reading these variables.
> Sure they have, but if they also read these env vars, then they will pick up
> any set values.
> But these env vars are generic and where never meant to be set by the
> desktop environment (especially not silently automatically), but rather
> manually by the user.

Those variables are set because you manually entered them in Settings.

> > > 2) Since GNOME's policy is typically to remove features
> > You know, people would take you more seriously if you didn't throw in a few
> > gems like these.
> Well as a matter of fact, this is often the case, isn't it?

No.

> Some people like
> it some not. My comment here was not necessarily meant to condemn this
> philosophy

Your comment had nothing to do with philosophy, and, as Andre pointed out, this is not the place for philosophical debates either.

> So no need to feel offended =)

Your comment was offensive and inaccurate.

> > Basically what you are asking for is a way to have application specific
> > network settings.
> No, at least not in the ticket ;-)

Most of the things you are saying on this bug make no sense. As far as I can make out, you want to use different applications with different network settings, and there is no good way to do that at the moment. You dislike setting these variables as a result of that.

When designing solutions to problems, it is important to consider the bigger use-case. A bottom-up approach starting with technical details doesn't work.

> I'm fine with GNOME setting one
> global proxy for everything, but then please only for GNOME programs,
> respectively those which explicitly use GNOME's lib/API/etc. to discover
> these settings and hopefully document their behaviour properly.

So now, the vast majority of users will have to read and understand each and every program to find out whether it is a "GNOME program" or not, as per your definition. Just because you have an extremely special set-up and don't want to unset a few environment variables yourself.

(In reply to Christoph Anton Mitterer from comment #8)
> (In reply to Egmont Koblinger from comment #6)
> > References, please?
> I already brought gpg as example =)

That is not a reference. Please don't wave the security flag so casually.

> and this is simply kinda common
> knowledge, I woudln't even know a particular "standard" or that like where
> it says the obvious.
> Storing passwords/etc. in env vars has all kinds of possible issues:
> - the problem already mentioned, that it's easily exported to places where
> it shouldn't

Which places? If an attacker gets shell access to your user account then you have all kinds of problems. The password of your network proxy is not the first thing you should be worried about.

I would expect programs that read this variable to treat it the same way they treat other passwords. If you are really paranoid you want the program to zero it out and unset it as soon as possible.

> - that people use it in scripts like e.g. "gpg --decrypt
> --non-existing-password-option "$GPG_KEY_PASSWORD"... completely forgetting
> that everyone will be able to see it

gpg and ssh agents, do exist, you know.



> > Note that introducing the http_proxy variable wasn't Gnome's idea.  It was a
> > common practice probably before gnome-terminal or maybe even Gnome
> > development started.
> I haven't said it was,.. what I said is...
> 
> >  You might argue that it's broken by design, but that's
> > what we have to live with.
> ... that it was not meant to be automatically set.
> It's rather a convenience option that users can set in their .bashrc so that
> they don't have to do --proxy foo every time they invoke e.g. wget.
> But non of these programs that use it said (or documented): "Oh and btw. we
> use now http_proxy so that we can get the GNOME/KDE proxy settings."
> 
> 
> > This is the big difference between us.  You think in terms of environment
> > variables: bits here and there, a bottom-up approach and you freak out when
> > we change a bit without warning you about it.  I (and apparently Debarshi
> > too), on the other hand, think about the overall user experience: we just
> > want to make this work out of the box in as many apps as reasonably
> > possible, whatever the necessary technical bits are.
> Well as I've said before... sometimes out-of-the-boxness can also got way to
> far, which is typically then the case when the system reacts in a way that
> cannot be commonly expected (either by common sense or by long standing
> practise)... or when it tries to be smart about things were it cannot be
> really smart. In the end it should still be the user who controls the system
> and not vice versa.
> 
> 
> 
> > I have a feeling that you would equally dislike any other approaches I
> > outlined in comment 1, since they're all about settings these variables
> > somewhere else other than gnome-terminal, whereas you argue for not setting
> > these variables at all – do I see it correctly?
> As I've said before, I don't think you can make it work correctly with env
> vars, simply because you cannot easily alter them once they were set,
> especially not portable over all shells.
> So on the technical level I see no way to make it properly working, unless
> by using some proper API, as already mentioned several times.
> 
> My advise was then, to keep the feature, but make it configurable with
> defaulting to off, since it breaks things and is apparently a security leak.
> 
> 
> > I'm quite certain that this
> > is not going to happen.
> hmm I'm afraid,... well I'll forward this then Debian, so the the issue
> might be fixed at least at the distro level.
> 
> 
> Cheers,
> Chris.

Look, I gave you several examples now, why this feature does and cannot work and even, having my security expert hat on, some quite clear cases of security issues of it.

You keep ignoring all that, basically justifying it with the need for the "overall-experience™" and that breakage would only happen for a minor number of people which you either don't care for or... I don't know.
And the security implications seem to be simply ignored.

It's a bit as if you'd say "well, our application potentially exposes your password, but only if you use a password, and only if you hostname starts with foo - therfore this ain't a security issue... and even if it was, it [would] be other user's duty to check that silent setting".
Now I don't find any further arguments against this.

I guess I've already brought enough examples why this feature doesn't work and is risky in many situations... so I see no point in bringing even more that would be ignored.

So as this is apparently not going to be fixed, I take my liberty as original reporter and close the issue after making some final comments below.
As I've said before, this is not only a security issue, but trying to trick other programs into using GNOME settings when they did not choose to use them, is IMO simply bad design and behaviour.


(In reply to Debarshi Ray from comment #10)
> > As I said, it *may be convenient* for some people, but as I pointed out
> > above it also has all kinds of flaws.
> I will say "most", not "some". Your requirements are clearly not what most
> people using proxies have.
If rm would remove all files for people whose MAC address starts with CA:FE:BA:BE ... it would surely just hit "some" people,... nevertheless they'd surely be pissed off.


> > But these env vars are generic and where never meant to be set by the
> > desktop environment (especially not silently automatically), but rather
> > manually by the user.
> Those variables are set because you manually entered them in Settings.
Explained that before,... non obvious settings of generic env vars... bad behaviour... especially as it cannot be technically kept up to date properly.


> Most of the things you are saying on this bug make no sense.
Uhm? o.O
I think I've answered all question of Egmont and yours... so I cannot quite follow why something shouldn't make sense

> As far as I can
> make out, you want to use different applications with different network
> settings, and there is no good way to do that at the moment.
While this happens in practise (i.e. that I want that) it's not the main reason for this bug.
As I've said before, having per program proxy settings doesn't seem to be possible for GNOME programs anyway. I have no problem with that.
The actual main reasons are:
- the security hole and data leakage
- that proxy settings get stale in an open terminal, causing things to break when the proxy is changed

And a further reason was, that it's inappropriate to modify the settings/behaviour of non-GNOME program if these don't choose themselves to use the GNOME proxy settings.


> When designing solutions to problems, it is important to consider the bigger
> use-case. A bottom-up approach starting with technical details doesn't work.
You can't just break other existing applications and justify that by some use case,... sorry...


> > I'm fine with GNOME setting one
> > global proxy for everything, but then please only for GNOME programs,
> > respectively those which explicitly use GNOME's lib/API/etc. to discover
> > these settings and hopefully document their behaviour properly.
> So now, the vast majority of users will have to read and understand each and
> every program to find out whether it is a "GNOME program" or not, as per
> your definition.
The "vast majority"? I guess the "vast majority" uses a program like wget, or curl,... perhaps even reads the manpage of these programs, seeing options like --proxy and so on... none of them which states "if not specified by you, this is set by GNOME or other DEs".
Thus the vast majority will wonder: "Why does my wget try to use e.g. my Tor proxy to download a 4 GiB ISO image,... and why does even disabling the proxy in GNOME not fix the issue, but wget still uses the proxy??"


> Just because you have an extremely special set-up and don't
> want to unset a few environment variables yourself.
I don't think that having Tor configured as proxy is that special, is it?



(In reply to Debarshi Ray from comment #11)
> (In reply to Christoph Anton Mitterer from comment #8)
> > I already brought gpg as example =)
> That is not a reference. Please don't wave the security flag so casually.
Then what would you accept as "reference"? A paper written and signed by Werner Koch where he states that it's bad?
A bigger list of programs in the security/crypto area which don't do such things?
Sorry,... I really don't know what you want.

> > - the problem already mentioned, that it's easily exported to places where
> > it shouldn't
> Which places?
Please educate yourself about the shell execution environment (a starter may be http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12).
Also the C/POSIX standard library calls to fork/exec/pipe/etc. other processes, as these usually inherit the environment as well.

IOW: "places" = every single program run from such terminal where these variables were set.


> If an attacker gets shell access to your user account then you
> have all kinds of problems.
a) The main concern here is access to remote systems, where the attacker doesn't need access to your local user account.
b) Even if looking at the local side, and given that we have more and more confinement techniques to jail processes running under the same local user account, it's probably a very stupid idea to voluntarily export potentially sensitive credentials into any process started from such terminal, cause if such program has then a security hole, the attacker has even more than possibly just the program's context.


> I would expect programs that read this variable to treat it the same way
> they treat other passwords.
And expectation which is a) wrong (take as an example many programs that do bug reports, and simply send over as much information as they see, often including the programs environment (variables)) and b) just because you magically assume that any program handles these things securely, you wouldn't export e.g. you GPG_SECRET_KEY_PASSPHRASE to arbitrary programs, would you?


> > - that people use it in scripts like e.g. "gpg --decrypt
> > --non-existing-password-option "$GPG_KEY_PASSWORD"... completely forgetting
> > that everyone will be able to see it
> 
> gpg and ssh agents, do exist, you know.
Sure, and actually one of the main reasons of these programs (originally probably *the* main reason) was actually to avoid people doing such bad things like writing passphrases to envvars, password files or giving them as parameters.
Cause the agent actually has control (and does control) who can access that information and e.g. prevents any accidental things like exportation to remote sides.



That being said,... sorry for wasting your time (and mine) by reporting this bug and security issue.
Closing now.

Cheers.

(In reply to Christoph Anton Mitterer from comment #12)

> You keep ignoring all that

Not any more than you ignore our arguments.

> You can't just break other existing applications and justify that by some
> use case,... sorry...

Since when does setting some env vars for configuring an app count as "breaking" it? Oops, I've set my Gnome to speak German, and now my wget is also in German, but I didn't want that because wget is not a Gnome app, you broke it!!!

You kept saying that apps should "opt in" for Gnome changing their settings. Well, any app that supports $http_proxy has already opted in for the proxy to be told to them, no matter who sets this value.

> I don't think that having Tor configured as proxy is that special, is it?

No, it's not. Wishing for different proxy settings across your apps is.

> > > I already brought gpg as example =)
> > That is not a reference. Please don't wave the security flag so casually.
> Then what would you accept as "reference"? A paper written and signed by
> Werner Koch where he states that it's bad?

I was about to answer the same, but Debarshi was faster. Just throwing in an app name isn't a reference. At least a pointer to a design doc or discussion...

> Please educate yourself about the shell execution environment

André has already warned you; I think you've crossed the line again.

> a) The main concern here is access to remote systems, where the attacker
> doesn't need access to your local user account.

You keep ignoring the fact that these values aren't forwarded to remote systems.

> And expectation which is a) wrong (take as an example many programs that do
> bug reports, and simply send over as much information as they see, often
> including the programs environment (variables))

Have you filed security / data leakage bugreports against _these_ programs??

> That being said,... sorry for wasting your time (and mine) by reporting this
> bug and security issue.
> Closing now.

In comment 1 I stated I was open to improving the design. Your followup comments made me lose motivation.