Is there a standard method for searching and importing a pgp key using curl or wget?

I was going through verifying the download with a gpg signed shasum256 file and encountered the problem of trying to verify the gpg fingerprint.

So the standard method is to use gpg --recv-key KEYID that is shown when gpg --verify <file>.asc <file> is run, to auto import the public key from the public synchronizing key servers. But gpg now runs as an agent, and uses dirmngr to mediate this transfer. Unfortunately, dirmngr has never been able to honour the use of web proxies and so i'm left with trying to search and download using a web service and curl.

Doing this using a pool of key servers, results in added assurance that the keyfile you're downloading is legitimate across this pool. But this can be also be done if the user downloads the keyfile using https across multiple managed key service providers and verifies that the keyfiles are similar across board.

So are there sites with rest endpoints that i can call with just the keyid and get nice ascii armored results?

  • Can we assume that you already tried --keyserver-options http-proxy=http://yourproxy with gpg2 as described in the manual?
    – Kusalananda
    Jul 2, 2019 at 6:34
  • yes and manually editing the dirmngr configuration files. But do the keyserver options actually work for you? It never has for me Jul 2, 2019 at 6:37
  • I'm not able to test right now (travelling).
    – Kusalananda
    Jul 2, 2019 at 6:49

1 Answer 1


There are some servers which provide HTTP access to fingerprints, e.g. keys2.kfwebs.net; this will give you armored keys wrapped in simple HTML:

curl 'http://keys2.kfwebs.net/pks/lookup?op=get&search=0xdb221a6900000011'

will download the whole page,

curl 'http://keys2.kfwebs.net/pks/lookup?op=get&search=0xc465beb43c11b337' |
awk '/^-----BEGIN/ { inblock = 1 } /^-----END/ { inblock = 0; print} inblock'

will extract the public key.

You could also look at adapting parcimonie, a tool which refreshes keyrings over Tor, to work around your proxy problem.

Be aware that some keys have been poisoned, so it’s not a good idea to blindly import keys from the keyservers (not that it ever was, really). Also make sure to always check the full fingerprint, and use long key identifiers.

  • The only way to obtain keys is either through the keyservers ( defense by numbers, https transport security ) or on the developer page itself ( https transport security ), so from the keyservers which is a different source from the developer page represents the most low risk method. As for checking for full fingerprint, the documentation for gpg is really obscurantic and the only way anyone knows to do this as an accepted norm is through incidental comments on websites. Jul 2, 2019 at 8:14
  • My warning at the end wasn’t specifically related to the transport mechanism, but to the contents of the keys themselves. You’re right that out-of-band methods are preferable; if you’re verifying a download, you shouldn’t download the key from the same place. Checking full fingerprints has been the norm for as long as the web of trust has existed. Jul 2, 2019 at 8:19
  • On the other hand, the documentation for doing gpg --recv-keys always has the short key id, which in my mind isn't so great for a consistent stand on full fingerprints. Jul 2, 2019 at 8:23
  • The GnuPG manual does describe how to use short ids, but it also mentions alongside that, that “The use of key Ids is just a shortcut, for all automated processing the fingerprint should be used.” Unfortunately the rest of the documentation isn’t so great, yes. However verifying full fingerprints has always been the recommended practice when manipulating keys (regardless of how they are obtained, using short ids, long ids, fingerprints etc.). Jul 2, 2019 at 9:03
  • Great! i must've been reading the 2010 version or websites that always use short key ids as examples. Jul 3, 2019 at 4:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .