https://www.qubes-os.org/security/verifying-signatures/#1-ge...
If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.
Armed with a valid SSL cert, they MITM traffic. When a target downloads qubes they give them a tampered version, when a target downloads the master key, they give them a lookalike key.
The user can happily verify the tampered qubes with the lookalike key.
PGP proves nothing if you cannot verify that you have an authentic copy of the key.
Qubes gives some handwavy suggestions at how to check the key which do not work.
The first item "Use the PGP Web of Trust." cannot be done because the key isn't signed by anyone. The other suggestions are inapplicable or won't achieve anything if the target's network is being tampered with.
This is not some newfangled problem. PGP has the ability to sign keys for precisely this reason. The main Qubes developers should have personal PGP keys which they use to sign the master key. Their personal keys should be certified by other FOSS developers that they've met (maybe the master key too). Then people who are interested in obtaining high confidence in the key can inspect the chain from their own key to the qubes masterkey.
Obviously not everyone will perform careful validation, but if some do then substituting the key becomes riskier. Unfortunately not only is the key not verifiable at the moment, but the current situation is looks pretty similar to what an ongoing key replacement attack would look like.
> If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc.
The malicious party would have to compromise a lot of websites for that: https://www.qubes-os.org/faq/#should-i-trust-this-website.
Apart from that, let's see what the developers will reply: https://qubes-os.discourse.group/t/there-is-no-way-to-valida....
(I'm not suggesting that it is-- it's just an extremely bad failure mode when you undermine your users ability to detect key substitution attacks by always looking like a key substitution is in progress).
Then again, it's not just them. OpenSSL did this previously too-- replaced their key and the only source for the new key was the same https site as the software, and the key was signed by nothing and it stayed this way for a month.
During which time most Linux distributions shipped the new update, which presumably means that they're not doing due diligence either. OpenSSL promptly fixed it after I reported that I couldn't validate their key.
Fedora itself now has a nearly non-verifyable key, unlike qubes they don't even have a master key that signs their release keys or sign new release keys with old ones. Presumably Qubes picked up their bad practices from Fedora.
It used to be that various developers at redhat would sign the fedora keys and post the signatures to the keyservers, but the DOS attacks on keyservers mean they can't do this anymore.