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?
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:
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.
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).
I think we have to give up on gpg keyservers entirely.
Iâve recently created a wiki template Template:Git clone verify - Whonix but it does not cover Qubes TemplateVMs yet, which are even more complicated due to lack of networking.
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?
The problem youâre addressing (if any)
Importing a GPG key using gpg --recv-keys will fail (due to a bug in GPG) in an offline qube, such as a template qube, even if a HTTP proxy is used. Furthermore, GPG has substantial attack surface of its own, and exploitable bugs in its parsing of keys have occurred in the past.
Describe the solution youâd like
Provide a qubes-receive-key command that uses a disposable qube and/or the updates proxy to retrieve the key by fingerprint, and then sanitizes the key and ensures it actually has that fingerprint.
Given https://keys.openpgp.org/ is not part of the sks network and is supposedly functional, I gather we no longer have to worry about the retrieval of keys issue?
gpg: keybox â/home/user/.gnupg/pubring.kbxâ created
gpg: key 0xEE8CBC9E886DDD89: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1
We should reference the onion then in relevant wiki instructions?
Before adding a set of default keyservers I tested gpg key imports and it seems to be able to pull it from somewhere despite not having one defined in the settings. Any idea how it does this?
Locate a key using DNS CERT, as specified in RFC-4398.
pka
Locate a key using DNS PKA.
dane
Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt.
wkd
Locate a key using the Web Key Directory protocol.
ldap
Using DNS Service Discovery, check the domain in question for any LDAP keyservers to use. If this fails, attempt to locate the key using the PGP Universal method of checking âldap://keys.(thedomain)â.
ntds
Locate the key using the Active Directory (Windows only).
