[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

gpg --recv-keys fails / no longer use keyservers for anything

Running gpg --recv-keys in a Debian VM fails

For example:

gpg --recv-keys 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA
gpg: keyserver receive failed: Server indicated a failure

This occurred while while running the command in a Qubes 3.2 Debian VM and has been reproduced by a second user. However, this is unrelated to Qubes / Whoinx / TemplatesVMs and looks to be general gpg bug.

Has anyone encountered this issue or know of any solutions that would allow this command to complete successfully?

This issue was first mentioned in Whonix forums long wiki edits thread.

1 Like

Could the GPG keyserver chosen from the pool have been temporarily down? I see that sort of thing quite a bit. THe command above worked for me on a regular VM.

And/or it could be an outbound firewall issue? I think the default remote port for keyservers is TCP 11371?

You could force a keyserver, as well as forcing HTTP port 80 on the end, e.g:

gpg --keyserver hkp://ipv4.pool.sks-keyservers.net:80 --recv-keys 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA
1 Like

Probably not keyserver problem / not network issue / not user error.

Works for me on Debian. Keyservers key.gnupg.net / pgp.mit.edu don’t work for me on Debian.

gpg: keyserver receive failed: Server indicated a failure

gpg: keyserver receive failed: Server indicated a failure

Had the same error Qubes-R3.2 Debian-9 AppVM.

Added package https://packages.debian.org/stretch/dirmngr and was able to download key.

gpg --recv-keys 916B8D99C38EAF5E8ADC7A2A8D66066A2EEACCDA

Works for me.

Qubes builder gpg key fetching during build was recently disabled due to never ending gpg keyserver issues.


https://github.com/GrapheneOS/hardened_malloc/issues/82

No luck can try like 10 times and wait ages. If you “google” for just the fingerprint in quotes (to specific results) you find multiple people having this issue. Qubes just removed keyserver fetching for Qubes builds due to unreliability. I guess keyservers are death and won’t come back (due to GDPR).

A bug in gpg, sks(?) is preventing gpg keys from downloading. This can prevent users from downloading Tor project key in Tor Versioning. It looks like the gpg aspect of this was fixed?

Maybe find a alternate method of downloading Tor project key if sks fails in Wiki instructions.

sudo apt-key adv --keyserver jirk5u4osbsr34t5.onion --recv-keys A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89

Executing: /tmp/apt-key-gpghome.DvzZefKIG4/gpg.1.sh --keyserver jirk5u4osbsr34t5.onion --recv-keys A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
gpg: packet(13) too large
gpg: read_block: read error: Invalid packet
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0

First 3 links relate to the issue. Micah Lee brought up something interesting (3rd link).

Other reports of Tor Project key download fails. No good solutions here. wget

1 Like

I think we have to give up on gpg keyservers entirely.

I’ve recently created a wiki template https://www.whonix.org/wiki/Template:Git_clone_verify but it does not cover Qubes TemplateVMs yet, which are even more complicated due to lack of networking.

https://www.whonix.org/wiki/Tor_Versioning#Add_the_Tor_Signing_Key has instructions for Qubes, but it’s not a wiki template.

I wonder if we can have a generic wiki template (or one for git / one of archives) for gpg verification. Help welcome.

High-risk users should stop using the keyserver network immediately.

source:

Also on same subject:

https://dkg.fifthhorseman.net/blog/openpgp-certificate-flooding.html

The first thing that needs to be resolved for the wiki is donwloading TPO keys. There keys are not available for donwload by git clone(?) so maybe scurl should be used?

1 Like

Ticket created just now.

stop using gpg keyservers / provide OpenPGP keys for download as files from torproject.org
https://trac.torproject.org/projects/tor/ticket/31090#ticket

2 Likes