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. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to software-properties in Ubuntu. https://bugs.launchpad.net/bugs/1433761 Title: apt-key and add-apt-repository don't honor Acquire::http::Proxy Status in software-properties package in Ubuntu: New Bug description: When setting the proxy server globally on the system for the APT package manager, add-apt-repository ignores the setting. This issue is present on all versions of Debian that I have tested. # cat /etc/apt/apt.conf.d/80proxy Acquire::http::proxy "http://w.x.y.z:nnnn/"; # apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 5A9A06AEF9CB8DB0 Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.TIa517Kcw8 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-squeeze-automatic.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-squeeze-stable.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-wheezy-automatic.gpg --keyring /etc/apt/trusted.gpg.d/debian-archive-wheezy-stable.gpg --keyring /etc/apt/trusted.gpg.d/saltstack-salt.gpg --keyserver keyserver.ubuntu.com --recv-keys 5A9A06AEF9CB8DB0 gpg: requesting key F9CB8DB0 from hkp server keyserver.ubuntu.com gpg: keyserver timed out gpg: keyserver receive failed: keyserver error This has serious repercussions. Unattended installs such as juju, maas, etc are all affected for anyone who is working behind a proxy. This is the case for most enterprise environments where such maas and juju setups will be tested out, and as such has great repercussions for Canonical as a viable supplier of OpenStack environments: if your product fails to install, you're not going to get the business. Considering that: * The setting to use already exists in /etc/apt/apt.conf and that all other tools use this correctly * The serious impact of this issue for downstream projects and Debian usage in the enterprise * The long time this issue has been standing and has affected people I suggest that this either 1) be fixed, or 2) the apt-key and add-apt-repository programs are renamed so that it is made clear they are not part of the APT suite of programs and therefor cannot be trusted to behave as if they were part of APT. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1433761/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp