Comment 9 for bug 1044156

Revision history for this message
Paul Abrahams (abrahams) wrote :

I don't think that ufw/iptables has anything to do with the problem. Look at this:

root@Lenovo-Z580:~# host pgpkeys.mit.edu
pgpkeys.mit.edu is an alias for CRYPTONOMICON.mit.edu.
CRYPTONOMICON.mit.edu has address 18.9.60.141
root@Lenovo-Z580:~# gpg --keyserver hkp://pgpkeys.mit.edu --recv-keys A8AA1FAA3F055C03
gpg: requesting key 3F055C03 from hkp server pgpkeys.mit.edu
?: pgpkeys.mit.edu: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
root@Lenovo-Z580:~# gpg --keyserver hkp://18.9.60.141 --recv-keys A8AA1FAA3F055C03
gpg: requesting key 3F055C03 from hkp server 18.9.60.141
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key 3F055C03: public key "Launchpad PPA for Daniel Richter" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)

If you use the Web address of the keyserver, the key retrieval fails. If you use its IP address, the key retrieval succeeds. If there was any kind of firewall problem involved, either both of these should succeed or both of these should fail (or it's a pitiful firewall indeed). The problem seems to lie in the way that gpg resolves URLs, or perhaps in how it finds a nameserver to resolve them.