gnupg2 appears to ignore http_proxy, fails to retrieve keys

Bug #1625848 reported by Stéphane Graber on 2016-09-20
12
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
Launchpad Janitor (janitor) wrote :
Download full text (10.2 KiB)

This bug was fixed in the package gnupg2 - 2.2.4-1ubuntu1

---------------
gnupg2 (2.2.4-1ubuntu1) bionic; urgency=medium

  * Merge from Debian unstable, remaining changes:
    - debian/gnupg2.udev:
      - Add udev rules to give gpg access to some smartcard readers;
        Debian #543217.
      - udev rules to set ACLs on SCM smartcard readers.
    - Add breaks for software-properties-common at 0.96.24.3 or lower.
    - Honor http_proxy= environment variables by default in the systemd
      user session dirmngr service. LP: #1625848
    - Export GPG_AGENT_INFO in the systemd-environment-generator too.

  * Dropped changes:
    - Removed user session upstart support.
    - Removed gpg-agent.service changes, use Debian's environment generator instead.
    - Patch to set GNUPGHOME for tests, fixed in debian/upstream.

gnupg2 (2.2.4-1) unstable; urgency=medium

  * New upstream release
  * do not use uupdate (we use gbp-import-orig)
  * dirmngr: cannot avoid idling in current arrangement
  * adjusting fixes to gpgsm defaults
  * prefer SHA-512 specifically on personal-digest-preferences.
  * refresh patches
  * Standards-Version: bump to 4.1.3 (no changes needed)
  * drop unnecessary lintian override
  * reflect actual requirement for libassuan
  * import bugfixes from upstream

gnupg2 (2.2.3-1) unstable; urgency=medium

  * New upstream release
  * refreshed patches

gnupg2 (2.2.2-1) unstable; urgency=medium

  * new upstream release.
  * avoid testsuite delays from excess socket waiting
  * clean up trailing whitespace in debian/{rules,changelog}
  * drop patches already upstream
  * refresh remaining patches

gnupg2 (2.2.1-5) unstable; urgency=medium

  * block ptrace on scdaemon as well as gpg-agent (Closes: #878952)

gnupg2 (2.2.1-4) unstable; urgency=medium

  * restore lintian override, because ftp-master isn't yet running lintian
    2.5.55 (see #877999 for more details)

gnupg2 (2.2.1-3) unstable; urgency=medium

  * bugfix for multiple keyrings (Closes: #878812)
  * drop an unnecessary lintian override

gnupg2 (2.2.1-2) unstable; urgency=medium

  * adopt bugfixes and documentation improvements from upstream
  * reorganize debian/patches for simpler maintenance
  * move gnupg-l10n to Section: localization
  * Standards-Version: bump to 4.1.1 (no changes needed)

gnupg2 (2.2.1-1) unstable; urgency=medium

  * New upstream release
  * drop patches already applied upstream

gnupg2 (2.2.0-3) unstable; urgency=medium

  * avoid FTBFS when TZ=UTC-12 (Closes: #874617)

gnupg2 (2.2.0-2) unstable; urgency=medium

  * dirmngr and gpgv-static are Multi-arch: foreign (Closes: #874111)
  * update to stronger cryptographic defaults.
  * use upstream gpg-agent-browser.socket systemd user service
  * publish SSH_AUTH_SOCK for wayland users (Closes: #855868)

gnupg2 (2.2.0-1) unstable; urgency=medium

  * New upstream release.
  * drop patches already upstream
  * scdaemon: bugfix from upstream for large ECC keys
  * Standards-Version: bump to 4.1.0 (no changes needed)

gnupg2 (2.1.23-2) unstable; urgency=medium

  * add openssh-client to build-deps for testing

gnupg2 (2.1.23-1) unstable; urgency=medium

  * New upstream release
  * move to unstable...

Changed in gnupg2 (Ubuntu):
status: In Progress → Fix Released
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.