Cannot install Google Earth Pro on Fedora 43: does not verify: no digest

Ask Fedora
,
1

I am unable to install the latest version of Google Earth Pro on Fedora 43. I’ve looked at similar problems with other packages and suspect this has to do with the switch to RPM v.6, or possibly changes to Fedora’s “crypto policies”. I’m hoping that someone who knows more about this than I do can:

  1. confirm my suspicion or provide an alternate explanation.
  2. assuming that it’s related to old packaging on Google’s part, point me at the info I’d need to write an effective bug report against the Google Earth project.

All of the following was done on a freshly updated system:

$ uname -a
Linux chill 6.18.12-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 16 18:58:26 UTC 2026 x86_64 GNU/Linux

$ update-crypto-policies --show
DEFAULT

$ rpm --version
RPM version 6.0.1

$ sudo dnf upgrade -y
Updating and loading repositories:
Repositories loaded.
Nothing to do.

Here’s what happens when I try to install:

$ sudo dnf install -y google-earth-pro-stable-current.x86_64.rpm
Updating and loading repositories:
Repositories loaded.
Package                                               Arch         Version                                               Repository                         Size
Installing:
 google-earth-pro-stable                              x86_64       7.3.7.1094-0                                          @commandline                  244.4 MiB

Transaction Summary:
 Installing:         1 package

Total size of inbound packages is 74 MiB. Need to download 0 B.
After this operation, 244 MiB extra will be used (install 244 MiB, remove 0 B).
Running transaction
Transaction failed: Rpm transaction failed.
Warning: skipped OpenPGP checks for 1 package from repository: @commandline
  - package google-earth-pro-stable-7.3.7.1094-0.x86_64 does not verify: no digest

I’ve tried temporarily switching to the “LEGACY” crypto policy, but that made no difference.

Installing with rpm and the “—nodigest” flag succeeds, but I suspect that future updates through DNF would then fail, and I don’t really want to bypass system security.

$ sudo rpm -ivh --nodigest google-earth-pro-stable-current.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:google-earth-pro-stable-7.3.7.109################################# [100%]
Redirecting to /bin/systemctl start atd.service
warning: commands will be executed using /bin/sh
job 6 at Tue Feb 24 12:52:00 2026

Here’s information about the RPM file header:

$ rpm -qip google-earth-pro-stable-current.x86_64.rpm
Name        : google-earth-pro-stable
Version     : 7.3.7.1094
Release     : 0
Architecture: x86_64
Install Date: (not installed)
Group       : Applications/Internet
Size        : 256277573
License     : Multiple, see http://www.google.com/earth
Signature   :
              RSA/SHA512, Wed 04 Feb 2026 02:56:57 PM, Key ID 32ee5355a6bc6e42
              RSA/SHA512, Wed 04 Feb 2026 02:56:58 PM, Key ID 32ee5355a6bc6e42
Source RPM  : google-earth-pro-stable-7.3.7.1094-0.src.rpm
Build Date  : Wed 04 Feb 2026 02:48:46 PM
Build Host  : 2073fa655d64
Relocations : /opt
Packager    : Google Earth Team <google-earth-support@google.com>
Vendor      : Google Inc.
URL         : http://www.google.com/earth
Summary     : Google Earth
Description :
Explore, search and discover the planet

Google Earth lets you fly anywhere to see satellite imagery, 3D buildings, 3D trees, terrain, Street View, planets and much more.

And here’s some information about the keys in the RPM file:

$ rpm -Kv google-earth-pro-stable-current.x86_64.rpm
google-earth-pro-stable-current.x86_64.rpm:
    Header OpenPGP V4 RSA/SHA512 signature, key fingerprint: eb4c1bfd4f042f6dddccec917721f63bd38b4796: OK
    Header SHA3-256 digest: NOTFOUND
    Header SHA256 digest: NOTFOUND
    Header SHA1 digest: NOTFOUND
    Payload SHA3-256 digest: NOTFOUND
    Payload SHA3-256 ALT digest: NOTFOUND
    Payload SHA512 digest: NOTFOUND
    Payload SHA512 ALT digest: NOTFOUND
    Payload SHA256 digest: NOTFOUND
    Payload SHA256 ALT digest: NOTFOUND
    Legacy OpenPGP V4 RSA/SHA512 signature, key fingerprint: eb4c1bfd4f042f6dddccec917721f63bd38b4796: OK
    Legacy MD5 digest: NOTFOUND

Here are my installed keys from Google, which seem to match the key in the file:

$ rpmkeys --list | grep -i google
eb4c1bfd4f042f6dddccec917721f63bd38b4796 Google Inc. (Linux Packages Signing Authority) <linux-packages-keymaster@google.com> public key

I’m happy to provide any other information that’s needed.

1 Like
What now? Google Earth Pro fail
2

Just confirming, I just hit this as well (with dnf update rather than install). It’s a new problem, because yesterday’s update ran perfectly normally. The first step would be to lodge a bug on the fedora bugzilla at bugzilla.redhat.com, but I strongly suspect that Fedora just installs whatever google ships without testing, so it’s likely to get referred upstream. My experience on reporting bugs to google is of a black hole. For the moment, I’m running with

sudo dnf update --exclude=google-earth-pro-stable

but that will get pretty stale very soon. Unfortunately I can’t find any containerised versions either.

3

This is interesting…
So both google earth pro and google chrome are signed by the same OpenPGP V4 key fingerprint
eb4…796 according to rpm -Kv

the google chrome package’s rpm -Kv output is materially different in other respects showing:

Header SHA256 digest: OK
Payload SHA256 digest: OK

I think this is the underlying issue. For whatever reason that earth pro rpm -Kv output is not showing that the Header and payload digests are expected for the key.

This suggests to me that the earth pro package is being built using a process and tooling that adheres to the rpm v3 specification.. which was superseded by the rpm v4 specification in the early 2000s. If I’m reading the upstream pull request commentary linked from RPM version 6 release notes correctly… the last version of rpm that could produce v3 packages was in the year 2000.

So if my analysis is correct, this is not a bug in Fedora. RPM 6.0 dropped support for the rpm v3 specification deliberately.

I’ve checked both google chrome and google cloud init and they do not have this problem as they appear to adhere to the v4 specification and the header and payload digests expected in the v4 rpm specification exist.

If I’m correct in my analysis of what I am seeing, what needs to happen is google needs to update its google earth packaging process to be rpm v4 specification compliant… basically any upstream rpm release from the year 2001 or onward.

1 Like
4

Querying the RPMVERSION and RPMFORMAT tags may help:

rpm -qp --qf '%{RPMVERSION} %{RPMFORMAT}\n' ./google-earth-pro-stable-current.x86_64.rpm 
4.11.1 4

rpm -q --qf '%{RPMVERSION} %{RPMFORMAT}\n' google-chrome-stable
4.17.0 4

google-earth-pro-stable-current has been build with an older version.

5

thanks you for the query line for the rpm build specifics. Assuming this isnt some sort of exotic tooling…and that is accurate information…

We have to do some historic digging to be sure.. and find a copy of rpm 4.11.1 to confirm…
But doing a little more historical digging it appears that 4.14.0 release notes indicate that the SHA256 header and payload digest started to be added automatically into the immutable header with that release. So based on the release note information.. this is self consistent with the information you’ve provided.

So if my reading of the 4.14.0 release notes at rpm.org upstream is correct.. then yes anything built with an rpm 4.x older than 4.14.0 released in 2017 is probably going to throw the digest error now even though its producing a v4 format package. So this is probably a bug, as the v4 packages built with rpm 4.x prior to 4.14.0 are probably intended to still work.

2 Likes
6

same problem, same suspicion

7

That query line is very cool! I can confirm the results against the file I was trying to install:

$ rpm -qp --qf '%{RPMVERSION} %{RPMFORMAT}\n' google-earth-pro-stable-current.x86_64.rpm
4.11.1 4
8

having the same issue rn

edit: for who wants to install google earth manually in dnf5 the default directory for cache is /var/cache/libdnf5, so you can just

sudo rpm -Uvh --nodigest /var/cache/libdnf5/google-earth-pro-*/packages/google-earth-pro-stable-7.3.7.1094-0.x86_64.rpm

1 Like
10

For some reason that default directory for cache was not working for me so I had to go to the Google Earth Pro website and download the rpm file to the desktop and then point the rpm command at that location. No idea why… Otherwise the command sudo rpm -Uvh --nodigest is correct.

11

I’m not sure this is actually google’s fault..

We’ve fallen into a cornercase here with how dnf and rpm6 interact.

My best speculation as to what has happened is rpm6 when explicitly dropping support for rpm v3 packaging format has and implict requirement that the v4 automatically generated header and payload digests are expected to be there and if not. its arguable that this was unanticipated regression for packages built with rpm v4.0 to rpm v4.13. And if you are using rpm directly there is a mitigation with the --nodigest option.

What we’ve fallen into is that there doesn’t appear to be a dnf level mitigation that exposes the rpm’s --nodigest option as part of dnf’s call to librpm in order to run the rpm transaction.

It appears that most of us, as users, in this thread are assuming that --nodigest should be implied with --nogpgcheck and it is not.

So there may be a bug here… maybe in rpm6… maybe in dnf5. It’s just wasn’t a bug that was user visible really until rpm6 dropped the v3 support.

It’s a little complicated.. its probably worth filing against dnf5 or having a discussion with a dnf5 maintainer.

2 Likes
12

I was having problems with this & reported it at,

It took a while to get it understood.

13

I just noticed that there is a flatpak version of Google Earth Pro on Flathub. It’s unverified and the reviews are not particularly good, so use at your own risk. I haven’t tried it so I can’t vouch for it.