Hi, Please do not CC me, I am subscribed to the list.
On Sun, May 03, 2015 at 03:36:10PM +0200, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > > This is inevitable with http_proxy, sadly, as there is no one place you can > > put things that will guarantee that all processes with get them as > > environment variables, and no guarantee that all processes will honour > > http_proxy anyway. > > This is true, but completely irrelevant in this case because the discussion > is not about ALL processes, it is about this particular instance of the > user's shell and apt-get. I don't believe it's irrelevant. My ambition in offering advice on the list is to offer practical advice. If it's a hopeless task to define the http proxy in just one place, then it's relavant IMHO to suggest it foolhardy to pursue that end. > > There are drawbacks to doing it. With -E it's potentially passing dangerous > > environment variables up to the super process. With whitelisting the > > http_proxy you're exposing yourself to attacks where a malicious > > person/process/whatever can point apt (or other things) at a malicious > > http_proxy. > > Once again, this is true but irrelevant for this discussion. Security is always relevant IMHO. We don't know enough of OP's environment to asses the risk. A safe answer is a more generally useful answer. > Sanitizing the environment against possible dangerous values is necessary > when granting LIMITED privileges with sudo, i.e. allowing to run only some > specific commands with elevated privileges. > > When granting UNLIMITED privileges, i.e. allowing to run any command with > sudo, sanitizing the environment is just a matter of convenience. We don't know whether the user shares the box, has other users who are limited, who would also be affected by the introduction of env_var in sudoers, nor about anyone else reading, copying or adapting the answer for their own purposes. > And when the address of the proxy will change, they will have a hard > figuring out what is wrong with apt-get. That is one of the drawback of your > proposed solution. That's a good point, apt does not provide adequate diagnostic output when the proxy server cannot be reached or does not respond. This is a bug that should be reported, if it hasn't already. This is the same whether you use -o or not, though. I agree that it's probably going to be more obvious if you've hand-typed the address at the time of the failure. > The major drawback, of course, is that you are suggesting a fix without > having understood the problem first. This is a very bad habit. I don't know quite how you have come to that conclusion, but regardless of what you think, this seems needlessly rude. Please try to be civil. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504202241.ga31...@chew.redmars.org
