Page MenuHome GnuPG

Vague error message: key X can't be retrieved (without telling anybody why)
Closed, WontfixPublic

Description

When gpg v2.0.30 is asked to retrieve a key, this hangs for no clear reason, and
then fails as follows:

Little-Net:~ minfrin$ gpg --keyserver pgp.mit.edu --recv X
gpg: NOTE: old default options file `/Users/minfrin/.gnupg/options' ignored
gpg: requesting key X from hkp server pgp.mit.edu
gpgkeys: key X can't be retrieved
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
gpg: keyserver communications error: keyserver helper general error
gpg: keyserver communications error: Invalid public key algorithm
gpg: keyserver receive failed: Invalid public key algorithm

  • There is the message "key X can't be retrieved" but this message does indicate

why (DNS failure? Timeout out? Dunno).

  • The message "gpg: keyserver communications error: keyserver helper general

error" is completely meaningless. What is a "general error" and what do I do
with that information?

  • The message "gpg: keyserver communications error: Invalid public key

algorithm" is also meaningless, if we cannot download the key, why are we
complaining about the algorithm used on a key that doesn't exist?

  • The message "gpg: keyserver receive failed: Invalid public key algorithm"

looks like the same message is bubbling up the stack, pointlessly.

Details

Version
2.0.30

Event Timeline

minfrin set Version to 2.0.30.
minfrin added a subscriber: minfrin.

The keyserver helpers programs which are the cause for some not too useful error
messages have been removed from 2.1. Thus the error messages are different and
might be better - at least the dirmngr, responsible for fetching keys, can
create a detailed log file.

I tagged this as wontfix because we won't do any chnages to 2.0 anymore, its
EOLed for the end of the year.

Please feel free to re-open this bug if you experience such problems asl with
2.1.19 or higher.

Thanks for reporting.

marcus moved this task from Done to Backlog on the gnupg board.
marcus claimed this task.