Google-chrome update for Fedora-37

User Support
1

Updates for google-chrome are failing with a complaint about an incorrect key for the package. The command (in DOM0 console):

sudo qubesctl --skip-dom0 --targets=fedora-37 --show-output state.sls update.qubes-vm

Yields:

        ID: update
  Function: pkg.uptodate
    Result: False
   Comment: Problem encountered upgrading packages. Additional info follows:
            
            result:
                ----------
                pid:
                    1908
                retcode:
                    1
                stderr:
                    Running scope as unit: run-r43c0dd65d0744625b69310cb0ba00f5a.scope
                    The GPG keys listed for the "google-chrome" repository are already installed but they are not correct for this package.
                    Check that the correct key URLs are configured for this repository.. Failing package is: google-chrome-stable-114.0.5735.90-1.x86_64
                     GPG Keys are configured as: https://dl.google.com/linux/linux_signing_key.pub
                    Error: GPG check FAILED
                stdout:
   Started: 20:49:52.641919
  Duration: 31239.832 ms
   Changes:

I’m running Qubes Release 4.1.2. I’m thinking this is a Google Chrome issue unrelated to Qubes or Fedora. Is that a correct assessment?

2

Hi.
this is probably not Qubes specific.
I didn’t search to fix your GPG key issue, but you could try to remove google-chrome
and installing it again. (or search to fix the issue :slight_smile: )

I would advice to just remove Chrome and install Brave instead.
It’s also Chromium based, so you won’t be lost with the appearance.

Anything that isn’t Chrome is better than the privacy nightmare that is Chrome (IMHO).

3

I won’t offer advice on the Google Chrome vs other browsers debate, only say that I understand your may have good reasons to prefer Chrome.

With that assumption made explicit, if those reasons don’t involve the few additions that Google makes to Chromium, then you might find simpler to install Chromium on Fedora?

Fedora’s official documentation actually offers a quick comparison along with the instructions to install both:

As a side note, if you actually want to read some thoughts that people on the forum have on a variety of web browsers, this (long!) thread may be of your interest too:

https://forum.qubes-os.org/t/secbrowser-alternatives/3560?u=gonzalo-bulnes

4

Actually, I only use Chrome in an appVM when it is absolutely necessary, which tends to be rarely. My preferred browser is Brave. But, I am diligent in keeping template packages up-to-date and the Chrome update failure blocked updates to other software; that was concerning. My temporary work-around was to manually update just the google-chrome-stable package with --nogpgcheck until I have a good understanding of the reason why this happened.

.

5

Updating a package with --nogpgcheck is generally not a Good Thing ™

You can download the package with --nogpgcheck, and it will be
saved to your system.
You then have a chance to examine the issue.
dnf --downloadonly --nogpgcheck install google-chrome-stable

Now you have a copy of the package, you can check what key signed the
package:
rpm -qi google-chrome-stable-114.0.5735.106-1.x86_64.rpm shows
Signature : RSA/SHA512, Sun Jun 4 03:42:49 2023, Key ID 4eb27db2a3b88b8b

So the package was signed with Key 4eb27db2a3b88b8b.

The Key in your repo definition is to be found at https://dl.google.com/linux/linux_signing_key.pub
You can download this key using wget, and examine it:

pub  dsa1024/A040830F7FAC5991
     created: 2007-03-08  expires: never       usage: SC  
     trust: unknown       validity: unknown
sub  elg2048/4F30B6B4C07CB649
     created: 2007-03-08  expires: never       usage: E   
[ unknown] (1). Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>

As you can see the package was signed with a completely different key.

If you go to a pgp key server like https://keyserver.ubuntu.com/, you
can search for a key. Entering 4eb27db2a3b88b8b takes you to one key
with uid -
Google Inc. (Linux Packages Signing Authority) linux-packages-keymaster@google.com
and you can see that the mysterious key is a subkey there.

So for some reason, this package has been signed with a different
google key.
This may be due to a policy change at Google, or a one off key signing
error. You can probably find news reports to help.

Obviously nothing here is specific to this package or to Google.
You can apply these trouble shooting steps any time you get a key
error.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
2 Likes
6

I had the same problem and was able to solve it by importing a new key with the following command

sudo rpm --httpproxy http://127.0.0.1:8082 --import https://dl.google.com/linux/linux_signing_key.pub

7

I believe that both of the following are authentic Google Linux package signing keys:

pub   dsa1024 2007-03-08 [SC]
      4CCA 1EAF 950C EE4A B839  76DC A040 830F 7FAC 5991
uid           [ unknown] Google, Inc. Linux Package Signing Key <linux-packages-keymaster@google.com>
sub   elg2048 2007-03-08 [E]

pub   rsa4096 2016-04-12 [SC]
      EB4C 1BFD 4F04 2F6D DDCC  EC91 7721 F63B D38B 4796
uid           [ unknown] Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com>
sub   rsa4096 2021-10-26 [S] [expires: 2024-10-25]
sub   rsa4096 2023-02-15 [S] [expires: 2026-02-14]

The 4EB27DB2A3B88B8B key under discussion is a subkey of the second one:

pub  rsa4096/7721F63BD38B4796
     created: 2016-04-12  expires: never       usage: SC  
sub  rsa4096/1397BC53640DB551
     created: 2016-04-12  expired: 2019-04-12  usage: S   
sub  rsa4096/6494C6D6997C215E
     created: 2017-01-24  expired: 2020-01-24  usage: S   
sub  rsa4096/78BD65473CB3BD13
     created: 2019-07-22  expired: 2022-07-21  usage: S   
sub  rsa4096/4EB27DB2A3B88B8B
     created: 2021-10-26  expires: 2024-10-25  usage: S   
sub  rsa4096/E88979FB9B30ACF2
     created: 2023-02-15  expires: 2026-02-14  usage: S

For what it’s worth, Google’s website also lists both of these keys:

https://www.google.com/linuxrepositories/

(Of course, I’m not suggesting that this page alone is definitive, but it’s another data point. You can gather additional data points by checking this page via Tor, VPNs, Internet cafe Wi-Fi, from different computers, etc. You can check with other users to see if the same key(s) are present in their systems at /etc/apt/trusted.gpg.d/google-chrome.gpg (or other distro equivalent). You can use the Web of Trust. And so on.)

Why two keys? Only Google knows, but if I had to guess, it’s probably because dsa1024 is outdated and less secure nowadays but has to be kept around (for now) for legacy support reasons.

In my Debian templates, I’ve been exclusively using the rsa4096 key for a while now without any problems. I seem to recall that I had to “separate” it from the dsa1024 key (at @Demi’s recommendation) by exporting just the rsa4096 key, so maybe they used to ship both keys in a single file or something. It’s been too long; can’t remember. But if that’s what happened, and they now ship the two keys separately, then I don’t know why they’d choose to have https://dl.google.com/linux/linux_signing_key.pub point only to the dsa1024 key, or why they’d only have one key download link instead of two. An oversight?

I also don’t know what the situation is with Fedora, as I haven’t used it in a while. It’s possible that Google recently decided to start signing Fedora packages with the rsa4096 key (which, again, they’ve already been doing on Debian for a while now), but that’s just a guess.

It’s puzzling that this worked for you, since it would seem that you imported a key that lacks the subkey used to sign the package, unless DNF somehow automatically updated/added/replaced the key (i.e., so you somehow got the newer rsa4096 key with the subkey used to sign the package) after you performed this manual import.

Also, it raises the question of which key you had before.

1 Like