File-descriptor leak in 1.4.0 hkp retrieval

[Phil Pennock]

Hi,

I think that I've found a file-descriptor leak in the retrieval of keys
via hkp, in keyserver/gpgkeys_hkp.c and verified still present in the
1.4 code, at least as of revision 1.47 (latest in that branch via the
CVSWeb interface, where I double-checked).

I have a shell-script wrapper around a couple of invocations of gpg
which attempts to retrieve all the keys which have signed some keys,
where the keyid isn't already in my public key-ring.  Basically,
a gpg --list-sigs, extract the not-known ones, uniqueify and pass
to --recv-key.

I just used this to retrieve some sigs, which asked for an unexpectedly
high number of keys.  That's my silly fault, but this exposed a
file-descriptor leak in the HKP handling.

-----------------------------< cut here >-------------------------------
gpg: key xxxxxxxx: public key "xxxxxxxxxxxx <xxx at xxxxxx.xxx>" imported
?: subkeys.pgp.net: Host not found
gpgkeys: HKP fetch error: Too many open files
?: subkeys.pgp.net: Host not found
gpgkeys: HKP fetch error: Too many open files
?: subkeys.pgp.net: Host not found
gpgkeys: HKP fetch error: Too many open files
?: subkeys.pgp.net: Host not found
gpgkeys: HKP fetch error: Too many open files
-----------------------------< cut here >-------------------------------

Looking at the code, it seems that in keyserver/gpgkeys_hkp.c in
get_key(), there's a missing call to http_close(&hd) which appears to
belong at the end of the function.

But I'm not a gnupg developer and don't know if this is anywhere near
right.  I've only looked at the code enough to identify what appears to
be a likely candidate (but it doesn't look as though the fd is kept for
persistence ...); sorry if this is a bogus report.

Thanks,
-Phil