Gpg: BAD signature from "Qubes OS Release 4 Signing Key" [full]

User Support
21

“If you have an authentic .DIGESTS file …”
At the time the first DIGESTS file failed verification. The second downloaded DIGESTS file passed. Both DIGESTS verified the iso. Thanks for the explanation of how it works.

1 Like
22

I got some similar issues with the 4.0.4

While downloading the most recent OS version 4.0.4. To install it on an old machine, the process went well. This time I took my time going through the verification of signatures and I had a few questions about the outputs.

Who’s signature are these?
5817A43B283DE5A9181A522E1848792F9E2795E9 or 51629CD41240D51DDAA773397AF9C6537BB6DE87

It’s not the master signing key nor is it the signing key for the Q4.0.4? Perhaps, it’s a developer signature but who’s?

(Here’s where I noticed it first)

[user@download ~]$ gpg2 -k "Qubes OS Release"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

(and again during this step)

[user@download ~]$ gpg2 --check-signatures "Qubes OS Release 4 Signing Key"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key
sig!3        1848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
sig!         DDFA1A3E36879494 2017-03-08  Qubes Master Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

At this point, I not trying to use an unstable version Since I inadvertently downloaded these signatures.

/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-templates-community
/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable

It may make sense, why I may have 2 versions of the OS? (or packages) by the following output.

[user@download ~]$ gpg2 -k "Qubes OS Release"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

Ultimately, I would like to get rid of the unstable versions and their signatures. How can I do that once I use the bootable USB on a different machine?

thanks,

23

Well, 5817A43B283DE5A9181A522E1848792F9E2795E9 is just the Qubes OS Release 4 Signing Key.

But it is. What makes you think it’s not?

As for 51629CD41240D51DDAA773397AF9C6537BB6DE87, I don’t recognize it, and I don’t know where it came from. Mysteriously, I have it in one of my qubes’ keyrings too, but I don’t know from where or when. Importantly, it is not signed by the QMSK or any other key in the aforementioned keyring and is not in the qubes-secpack, which makes me doubt its authenticity.

@marmarek, do you know anything about this key?

To clarify, these are paths to keys (not signatures) that are already in your filesystem, likely from a template. Merely having these doesn’t harm you in any way, nor does it mean you are or will use an unstable version.

This merely shows that you’ve imported these two public keys into your keyring. It doesn’t mean that you have any packages, and it doesn’t mean that you are or will use an unstable version.

If the only ISO you’ve downloaded is the current stable release (4.0.4), then you don’t have any unstable version to get rid of. There is currently no testing version listed on the downloads page, so if that’s where you got your download, you have nothing to worry about.

24

It is a key used to sign packages in “unstable” repository (described at How to install software in dom0 | Qubes OS). You can find the key in the qubes-release package: https://github.com/QubesOS/qubes-qubes-release/blob/master/RPM-GPG-KEY-qubes-4-unstable. It is intentionally not signed by QMSK, as it is never used to sign official releases, only experimental or debug packages.

2 Likes
25

@adw @marmarek Thanks for clarifying, the signature’s origin. In the past, I’ve had issues with disappearing documents from off-network apVMs and their respective folders. So, I hope you can appreciate my extrapolated concern.

So why would a verification signature process check the signature of a OS module we did not download?

Would there be way to check for or remove certain “modules” from an OS? i.e. anything that is “unstable or not practical”.

Lastly, if I had a spare machine and a day or so, I could do some testing ;however, this current machine is not for testing or evaluation.

thanks,

26

It doesn’t. As I explained above, you’re simply seeing that key in your own keyring.

That’s not how it works. You can think of each ISO as an atomic unit. Unless you build your own (which is something only people far more advanced than me do), you can’t add or remove anything from the ISO. So, a stable release ISO is just a stable release, and an unstable release ISO is an unstable release. If you’re using a stable release ISO, you won’t have anything unstable. There is no need to worry about checking for or removing any unstable “modules.”

27

@Libertad, @adw, and @marmarek,
Thanks for the question and the responses.
It helps to understand a little more how things are done.

1 Like
28

Thanks for explaining the processes. I am bit foreign to the OS and structure, so it helps. Thanks,

1 Like
29

Not just them, you should add anyone involved with data theft, extortion, espionage and stalking.

30

Answer me this… why are there three dates?

Imagine if Qubes is just NSA all the way? Now i suddenly don’t trust Qubes as much… I need an explanation… What’s up with the dates, and why can’t we know more about the masterkey and sign that one?
Openbsd seems more secure… Or if i’m just confused, you are the experts… What’s up with the dates? I need to learn PGP… One date seems the most logical to me anyways. One key and one date.