Comment 2 for bug 1433761

Thank you for taking the time to report this bug and helping to make Ubuntu better.

I understand why you expected apt-key and add-apt-repository to use the proxy you defined with Acquire::http::proxy in /etc/apt. But I'm not sure this is the only interpretation.

I expect "Acquire::http::proxy" to define the proxy for the apt repository itself. But apt-key and add-apt-repository don't actually access apt repositories at all - they access other metadata sources to set apt up instead. When configuring an "apt proxy", I might have even denied access to everything except to apt repositories themselves, and so apt-key and add-apt-repository wouldn't work in this case anyway.

Instead, I'd expect http_proxy and https_proxy environment variables to be used instead for these tools. But I believe (this needs to be checked) that add-apt-repository will need https to access Launchpad, and both tools need keyserver access which can't easily be proxied (they access a port most proxies wouldn't allow).

> The long time this issue has been standing and has affected people

Any difficulty with using add-apt-repository and/or apt-key via a proxy - reasonable. But that Acquire::http::proxy didn't configure apt-key and add-apt-repository - I'm not convinced, for reasons above. This is the first bug that I'm aware of that has mentioned this.

I understand the need to for proxy support for these tools for environments where direct access cannot be permitted. Maybe in this case only a socks proxy would do.

In any case, I think further discussion is needed, and piecemeal fixes will exacerbate the problem by adding confusion. I think this needs to be a blueprint-level item to fix behind-firewall-proxy-access for standard server/Openstack deployments that covers all use cases (cloud images, apt, keyserver, utilities like add-apt-repository) in a standard way.