gpgkeys doesn't find the key thru http proxy

Bug #789049 reported by Jorge Salamero Sanz
32
This bug affects 6 people
Affects Status Importance Assigned to Milestone
GnuPG
New
Undecided
Unassigned
gnupg (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: gnupg

gpgkeys (called from apt-key) doesn't find a key when using a http proxy (set from env http_proxy):

gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver-options http-proxy='http://10.51.0.95:3128/' --keyserver keyserver.ubuntu.com --recv-keys 10E239FF
gpg: requesting key 10E239FF from hkp server keyserver.ubuntu.com
gpgkeys: key 10E239FF not found on keyserver
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

on squid access.log:

1306490082.847 119 127.0.0.1 TCP_MISS/503 1478 GET http://keyserver.ubuntu.com:11371/pks/lookup? - DIRECT/91.189.89.49 text/html

while on a server without proxy works as expected:

gpg --ignore-time-conflict --no-options --no-default-keyring --secret-keyring /etc/apt/secring.gpg --trustdb-name /etc/apt/trustdb.gpg --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 10E239FF
gpg: requesting key 10E239FF from hkp server keyserver.ubuntu.com
gpg: key 10E239FF: "Launchpad Zentyal 2.0 series" not changed
gpg: Total number processed: 1
gpg: unchanged: 1

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnupg (Ubuntu):
status: New → Confirmed
Revision history for this message
Justin Dossey (jbd) wrote :

This bug is actually with GnuPG; I have reported it here:

https://bugs.g10code.com/gnupg/issue1799

As this affects all current users of Ubuntu who must use a proxy, I would recommend a Canonical-side workaround: configure the Squid servers supporting keyserver.ubuntu.com to serve requests when no Host: header is provided.

Currently, keyserver.ubuntu.com returns a 400 Bad Request when no Host: header is provided.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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