[Bug 1575877] Re: no_proxy ignored if https_proxy set

Patrick Cable pc at pcable.net
Mon May 2 15:56:47 UTC 2016


Sure thing. SRU to follow:

[Impact] 
This bug breaks users who use a proxy to access externally-hosted https apt repositories, but do not need to use a proxy to access internally hosted https apt repositories. Specifically, if a user has a https_proxy (or http_proxy and no https_proxy) setting in their environment, apt will no longer honor no_proxy. 

The normal http transport mechanism handles this fine, so backporting
will allow the expected behavior to work for both http and https
transports and save system administrators in some proxy environments
some frustration :-)

The previous behavior only checked for no_proxy in the event that
Acquire::https::Proxy or Acquire::http::Proxy was set. If they weren't,
then the https transport mechanism would pull environment variables, but
not check the no_proxy variable. This patch moves the no_proxy check
earlier in the code so that if no_proxy is set and the host matches the
function returns earlier.

[Test Case]
1) Ensure that Acquire::http::Proxy and Acquire::https::Proxy are not set in /etc/apt/apt.conf or /etc/apt/apt.conf.d/*.
2) Set https_proxy and no_proxy in the environment.
3) Run apt-get update. Apt will still attempt to use https_proxy on a host that is named in no_proxy. 

I tested this behavior in Trusty and Xenial. It'd be wonderful if I
didn't have to maintain a patch package for Trusty, but I understand if
you don't backport to out of date LTSes.

[Regression Potential] 
The patch does not introduce any new code to the branch, only a) moves the placement of a check that would return out the function earlier and b) changes the control flow such that a check for https_proxy and http_proxy will be performed each time HttpsMethod::SetupProxy() is called. I would say the potential for regression is low, though now each time SetupProxy is called it will be running getenv(). The performance overhead of such a thing is not significant.

[Other Info]
I worked with the folks in the debian-apt channel on oftc on this to reach an easier-to-read refactor and intended functionality, and they've already merged it in upstream. See http://anonscm.debian.org/git/apt/apt.git/commit/?id=42ba3fa1ec004acbddf5266559bd76428d904206. Given that this is my first patch, I'm not sure what else to address here. Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1575877

Title:
  no_proxy ignored if https_proxy set

Status in apt package in Ubuntu:
  Triaged

Bug description:
  Description:
  When using the https transport mechanism, $no_proxy is ignored if apt is getting it's proxy information from $https_proxy. If the source of proxy information is Acquire::https::Proxy set in apt.conf (or apt.conf.d), then $no_proxy is honored.

  Package Versions:
  1.0.1ubuntu2.13 on 14.04 LTS
  1.2.10ubuntu1 on 16.04 LTS

  Expected result:
  Apt would pull down my packages from my internal repository without trying to put it through the proxy.

  I've submitted a patch upstream that seems to fix the behavior, see
  https://github.com/Debian/apt/pull/14.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1575877/+subscriptions



More information about the foundations-bugs mailing list