GPG key partial match

Der Jitsi developers,
I’m following this tutorial: https://jitsi.org/blog/new-tutorial-installing-jitsi-meet-on-your-own-linux-server/

And I have a doubt about the GPG key match. I download the key with:
wget https://download.jitsi.org/jitsi-key.gpg.key
And got a key with the following public RSA:
$ gpg jitsi-key.gpg.key
gpg: directory ‘/root/.gnupg’ created
gpg: keybox ‘/root/.gnupg/pubring.kbx’ created
gpg: WARNING: no command supplied. Trying to guess what you mean …
pub rsa4096 2016-06-23 [SC]
66A9CD0595D6AFA247290D3BEF8B479E2DC1389C
uid Jitsi <dev@jitsi.org>
sub rsa4096 2016-06-23 [E]

follow the latest tutorial instead.

1 Like

Ok, I’m not an expert, but the latest tutorial does not explicitly talk about gpg checking, right? It just add it to the keyring here:

curl https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'

yes that’s true. OTOH you are downloading the software from the same domain than the key so it’s all a bit of theater security IMO. If you want it you can though.

wget https://download.jitsi.org/jitsi-key.gpg.key
--2020-07-16 13:35:03--  https://download.jitsi.org/jitsi-key.gpg.key
Résolution de download.jitsi.org (download.jitsi.org)… 52.38.151.149, 52.24.145.183
Connexion à download.jitsi.org (download.jitsi.org)|52.38.151.149|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 3071 (3,0K) [application/octet-stream]
Enregistre : «jitsi-key.gpg.key»

jitsi-key.gpg.key                              100%[=================================================================================================>]   3,00K  --.-KB/s    ds 0s      

2020-07-16 13:35:04 (148 MB/s) - «jitsi-key.gpg.key» enregistré [3071/3071]

gpg --list-packets jitsi-key.gpg.key 

# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
	version 4, algo 1, created 1466652163, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: EF8B479E2DC1389C
# off=528 ctb=b4 tag=13 hlen=2 plen=21
:user ID packet: "Jitsi <dev@jitsi.org>"
# off=551 ctb=89 tag=2 hlen=3 plen=567
:signature packet: algo 1, keyid EF8B479E2DC1389C
	version 4, created 1466652163, md5len 0, sigclass 0x13
	digest algo 10, begin of digest b7 ee
	hashed subpkt 2 len 4 (sig created 2016-06-23)
	hashed subpkt 27 len 1 (key flags: 03)
	hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
	hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
	hashed subpkt 22 len 4 (pref-zip-algos: 3 2 1 0)
	hashed subpkt 30 len 1 (features: 01)
	hashed subpkt 23 len 1 (keyserver preferences: 80)
	subpkt 16 len 8 (issuer key ID EF8B479E2DC1389C)
	data: [4094 bits]
# off=1121 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
	version 4, algo 1, created 1466652163, expires 0
	pkey[0]: [4096 bits]
	pkey[1]: [17 bits]
	keyid: D4B71E9D88D3172B
# off=1649 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid EF8B479E2DC1389C
	version 4, created 1466652163, md5len 0, sigclass 0x18
	digest algo 10, begin of digest 8f 7b
	hashed subpkt 2 len 4 (sig created 2016-06-23)
	hashed subpkt 27 len 1 (key flags: 0C)
	subpkt 16 len 8 (issuer key ID EF8B479E2DC1389C)
	data: [4093 bits]

gpg --search-keys EF8B479E2DC1389C

gpg: data source: https://192.146.137.141:443
(1)	Jitsi <dev@jitsi.org>
	  4096 bit RSA key EF8B479E2DC1389C, créé : 2016-06-23

Ok, I see, thanks!
I’m not expert on security, but I guess you always can get a man in the middle attack even if you are getting to the legit source. Obviously is a great level of paranoia too :stuck_out_tongue: