RESOLVED: Release Key for Q4.3 - Two **CRITICAL** Errors

Attempting to use the release signing key for v4.3.0 to verify the download of v4.3.0.

Out of band method fails:

[workstation]% gpg --receive-keys F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4
gpg: key 0x1C3D9B627F3FADA4: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1

In-band method (ie - downloading from the same website as the Q4.3.0 release) fails for the same reason:

[workstation]% gpg --import F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4.asc
gpg: key 0x1C3D9B627F3FADA4: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1

Appears the key was created incorrectly. Please update the key, and upload to the website and keyservers.

Also, and this should be DEFCON 1 level priority: the signing key is not signed by the previous signing key, or any other developers’ or other trusted keys.

https://keyserver.ubuntu.com/pks/lookup?search=F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4&fingerprint=on&op=index

It’s very important that whoever it is who handles the release keys actually understands GPG, not only copypasta but really comprehends the web of trust. Otherwise, there is no web of trust, no trust, so the iso can not be trusted.

Thank you.

Hi @TheMailman ,

Something must be wrong with your installation of gpg. If i download the key from the website and import them, it contains 1 key and was legit.

gpg --import qubes-release-4.3-signing-key.asc
gpg: Schlüssel 1C3D9B627F3FADA4: Öffentlicher Schlüssel “Qubes OS Release 4.3 Signing Key” importiert
gpg: Anzahl insgesamt bearbeiteter SchlĂĽssel: 1
gpg: importiert: 1
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: Tiefe: 0 gĂĽltig: 1 signiert: 21 Vertrauen: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Hinweis: Beglaubigungen von Dritten basierend auf dem SHA1 Algorithmus werden zurĂĽckgewiesen.
gpg: (benutze Option “–allow-weak-key-signatures” zum hinwegsetzen)
gpg: Tiefe: 1 gĂĽltig: 21 signiert: 8 Vertrauen: 20-, 0q, 0n, 0m, 1f, 0u
gpg: Tiefe: 2 gĂĽltig: 1 signiert: 0 Vertrauen: 1-, 0q, 0n, 0m, 0f, 0u
gpg: nächste “Trust-DB”-Pflichtüberprüfung am 2026-06-14

gpg --edit-key 1C3D9B627F3FADA4
gpg (GnuPG) 2.4.8; Copyright (C) 2025 g10 Code GmbH
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
pub rsa4096/1C3D9B627F3FADA4
erzeugt: 2024-04-10 verfällt: niemals Nutzung: SC
Vertrauen: unbekannt Gültigkeit: vollständig
[vollständig] (1). Qubes OS Release 4.3 Signing Key

1 Like

@murdoch

Thanks for the reply. I’m using the default gpg installation on Qubes whonix, and just now I checked on a different box. No problems with GPG.

There is however a problem with my initial ticket. I was incorrect to say that it failed when I downloaded from the website (which is how yours succeeded). I was confused, as I had also downloaded the key via browser from a keyserver (rather than on the command line) and that was what I tried and failed to install. I guess I had too much egg nog.

So it’s great that this error is not present in the key from the download website (which I now confirm, thank you for correcting me).

However there are still two problems:

  1. The key on the keyservers seems incomplete and/or out of date. This is still reasonably important. There really must be an “out of range” way to verify.

  2. The new key is not signed with the old key. That’s sketchy. It’s common practice to sign new keys with old keys, to establish the web of trust. However, it is signed with the Qubes Master Signing Key, which provides a similar function (maybe better). This is something that I don’t remember seeing before, and I do not have it, which isn’t ideal but seems likely that it’s my own oversight.

Can you confirm that you downloaded the Qubes Master Signing key with:

Key fingerprint = 427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494

sometime before December 19, 2025?

I guess that would be the best I could do here, due to not having downloaded that Master key previously.

Happy new year for you.

Hi @TheMailman ,
happy new year to you too.
The Release Key for Qubes OS 4.3 is signed by the Qubes Master Signing Key. This is used process since years, the several version release keys are not chained in any way.
As stated in documentation:

Many important Qubes OS Project assets (e.g., ISOs, RPMs, TGZs, and Git objects) are digitally signed by an official team member’s key or by a release signing key (RSK). Each such key is, in turn, signed by the Qubes Master Signing Key (QMSK) (0x427F11FD0FAA4B080123F01CDDFA1A3E36879494). In this way, the QMSK is the ultimate root of trust for the Qubes OS Project.

https://doc.qubes-os.org/en/latest/project-security/verifying-signatures.htm

gpg --list-sigs 1C3D9B627F3FADA4
pub rsa4096 2024-04-10 [SC]
F3FA3F99D6281F7B3A3E5E871C3D9B627F3FADA4
uid [vollständig] Qubes OS Release 4.3 Signing Key
sig 3 1C3D9B627F3FADA4 2024-04-10 [Eigenbeglaubigung]
sig DDFA1A3E36879494 2024-04-16 Qubes Master Signing Key

And because i am a Qubes OS user since version 3.x, i have the Qubes Master Signing key in my keychain for years (i think, sometimes around 2016, with Qubes OS 3.1)

3 Likes

I just realized I have it too, in a different VM that I use to verify the canary. So, all good (but the 4.3 key is incorrect on the keyservers.) Thank you.

Please read this page:

The new release signing key (RSK) is not supposed to be signed by the old RSK or any developer keys. It is supposed to be signed by the Qubes Master Signing Key (QMSK). This is not a mistake, oversight, or security weakness. It is part of the strong security model that the Qubes security experts carefully designed and set up 16 years ago and have been consistently executing ever since.

Yes, much better.

The QMSK has been the root of trust for the entire project since 2010. If you have a Qubes installation, you already have it, since there’s a copy of it in every qube.

1 Like

Verified, thank you.