Hacker News new | past | comments | ask | show | jobs | submit login

Signatures should go from the devs keys to the master key, not the other way around.

There is no such requirement anywhere. You can check the key by other means: https://qubes-os.discourse.group/t/there-is-no-way-to-valida...

Any other method of verification makes zero sense, it is bizarre the Qubes folks would think otherwise.

Beyond being bizarre, it makes it look compromised.

(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.

Can you please be more specific? How does it make Qubes look compromised? The Qubes website is absolutely not the only place to get the Master Key. See the discussion linked above: You can get the key from t-shirts, from qubes-os.org website, from Github, from the Qubes Discourse forum and other places. You can also find this key signed by different people.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact