gnupg2 appears to ignore http_proxy, fails to retrieve keys

Bug #1625848 reported by Stéphane Graber on 2016-09-20
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GnuPG2
Fix Released
Unknown
gnupg2 (Ubuntu)
Critical
Dimitri John Ledkov
Yakkety
Undecided
Dimitri John Ledkov

Bug Description

As seen in the LXC autopkgtest results: http://autopkgtest.ubuntu.com/packages/lxc

The source of those failures is that pool.sks-keyserver.net isn't allowed from within the autopkgtest environment. For that reason, LXC will switch to the http transport on port 80 when http_proxy is set in the environment.

Under gpgv1, this was causing gpg to grab keys through the specified proxy as required in the autopkgtest environment and in a lot of corporate environments where internet access is only available through proxy.

In gpgv2, it looks like dirmngr just entirely ignores any proxy variable and just attempts to fetch the key directly rather than through the proxy, leading to a failure.

### Xenial
iptables -I OUTPUT -p tcp --dport 80 -j REJECT
ip6tables -I OUTPUT -p tcp --dport 80 -j REJECT

root@xenial:~# gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 0xBAEFF88C22F6E216
gpg: requesting key 22F6E216 from hkp server p80.pool.sks-keyservers.net
?: p80.pool.sks-keyservers.net: Connection refused
gpgkeys: HTTP fetch error 7: couldn't connect: Connection refused
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver unreachable
gpg: keyserver communications error: public key not found
gpg: keyserver receive failed: public key not found

root@xenial:~# http_proxy=http://sateda.srv.mtl.stgraber.net:3128 gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 0xBAEFF88C22F6E216
gpg: requesting key 22F6E216 from hkp server p80.pool.sks-keyservers.net
gpg: key 22F6E216: "LXC pre-built images <email address hidden>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

### Yakkety
root@yakkety:~# iptables -I OUTPUT -p tcp --dport 80 -j REJECT
root@yakkety:~# ip6tables -I OUTPUT -p tcp --dport 80 -j REJECT

root@yakkety:~# gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 0xBAEFF88C22F6E216
gpg: keyserver receive failed: Connection refused

root@yakkety:~# http_proxy=http://sateda.srv.mtl.stgraber.net:3128 gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 0xBAEFF88C22F6E216
gpg: keyserver receive failed: Connection refused

Changed in gnupg2 (Ubuntu):
assignee: nobody → Dimitri John Ledkov (xnox)
Dimitri John Ledkov (xnox) wrote :

Upstream decides to ignore http_proxy by default, unless a config option is set.

I shall update the dirmngr.conf skeleton to include "honor-http-proxy" by default.

Existing users will be stuck being confused =(

Automatically, this can be adjusted with:

echo honor-http-proxy:0:1 | gpgconf --change-options dirmngr honor-http-proxy

this is a real pity for users on http_proxy networks, I used to suffer on such a network, and it was not nice.

Changed in gnupg2 (Ubuntu):
status: Triaged → In Progress
Changed in gnupg2:
status: Unknown → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gnupg2 - 2.1.15-1ubuntu4

---------------
gnupg2 (2.1.15-1ubuntu4) yakkety; urgency=medium

  * Honor http_proxy= environment variables by default, in the newly
    generated dirmngr.conf files. Existing users behing proxies should set
    honor-http-proxy in $GNUPGHOME/dirmngr.conf, see
    /usr/share/gnupg/dirmngr-conf.skel. LP: #1625848

 -- Dimitri John Ledkov <email address hidden> Wed, 21 Sep 2016 02:23:54 +0100

Changed in gnupg2 (Ubuntu):
status: In Progress → Fix Released
Stéphane Graber (stgraber) wrote :

So as I mentioned in-person, this fix isn't working.

For LXC, I ended up having our autopkgtest scripts divert dirmngr to dirmngr.orig and replace dirmngr with a call to "dirmngr --honor-http-proxy $@" which fixed this issue for us.

So it shows that dirmngr does respect the option when told about it, but it's certainly not told about it by default. In my environment I'm in a cleanly installed system in a freshly created user session.

Changed in gnupg2 (Ubuntu):
status: Fix Released → Triaged
Changed in gnupg2 (Ubuntu Yakkety):
assignee: nobody → Dimitri John Ledkov (xnox)
Changed in gnupg2 (Ubuntu Yakkety):
status: New → Won't Fix
Changed in gnupg2 (Ubuntu):
status: Triaged → In Progress
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.