Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Cannot install google-earth-ec-stable-7.3.7.1094-0.x86_64 does not verify: no digest Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. dnf runs automatically. 2. fails to install anything at all due to the google-earth failure. 3. Actual results: does not verify: no digest Expected results: Installs normally. Additional info: See also, https://discussion.fedoraproject.org/t/cannot-install-google-earth-pro-on-fedora-43-does-not-verify-no-digest/181852/8 May also be related to, An error in... /etc/cron.daily/google-chrome: warning: Certificate 7721F63BD38B4796: Subkey E88979FB9B30ACF2 is expired: The subkey is not live But unlikely, just a coincidence of "magagement". So this appears to be a complex issue related potentially to packaging or dnf/rpm interaction.
Tell us what dnf5 and rpm version you have istalled. Explain how do you invoke dnf5. "dnf runs automatically" is vague. Tell us how do have configured a repository with the google-earth-ec-stable-7.3.7.1094-0.x86_64 package.
Installed packages (dnf) dnf-data.noarch 4.24.0-1.fc43 updates dnf-plugins-core.noarch 4.10.1-6.fc43 fedora dnf-utils.noarch 4.10.1-6.fc43 fedora dnf4-plugin-notify-PackageKit.noarch 1.3.4-1.fc43 updates dnf5.x86_64 5.2.18.0-1.fc43 updates dnf5-plugin-automatic.x86_64 5.2.18.0-1.fc43 updates dnf5-plugins.x86_64 5.2.18.0-1.fc43 updates Installed packages (rpm) rpm.x86_64 6.0.1-1.fc43 updates rpm-build-libs.x86_64 6.0.1-1.fc43 updates rpm-libs.x86_64 6.0.1-1.fc43 updates rpm-plugin-audit.x86_64 6.0.1-1.fc43 updates rpm-plugin-selinux.x86_64 6.0.1-1.fc43 updates rpm-plugin-systemd-inhibit.x86_64 6.0.1-1.fc43 updates rpm-sequoia.x86_64 1.10.1-1.fc43 updates rpm-sign-libs.x86_64 6.0.1-1.fc43 updates rpmconf.noarch 1.1.12-4.fc43 fedora rpmconf-base.noarch 1.1.12-4.fc43 fedora /etc/yum.repos.d/google-earth-ec.repo : [google-earth-ec] name=google-earth-ec baseurl=http://dl.google.com/linux/earth/rpm/stable/x86_64 enabled=1 gpgcheck=1 OR /etc/yum.repos.d/google-earth.repo : [google-earth] name=google-earth baseurl=http://dl.google.com/linux/earth/rpm/stable/x86_64 enabled=1 gpgcheck=1 When I say dnf runs automatically I mean that, Systemd runs dnf5-automatic.timer & it runs dnf5-automatic.service according to the settings in my /etc/systemd/system/dnf-automatic.timer : OnCalendar=*-*-* 01:00:00 WantedBy=basic.target I don't consider that vague, I consider it a "standard" way to use dnf! I have now removed google-earth-ec-stable-0:7.3.7.10 on one machine. Now, on that machine, (with or without gpgcheck) # dnf install google-earth-ec-stable Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Installing: google-earth-ec-stable x86_64 7.3.7.1094-0 google-earth 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). Is this ok [y/N]: y [1/1] google-earth-ec-stable-0:7.3.7.10 100% | 0.0 B/s | 0.0 B | 00m00s >>> Already downloaded -------------------------------------------------------------------------------- [1/1] Total 100% | 0.0 B/s | 0.0 B | 00m00s Running transaction Transaction failed: Rpm transaction failed. - package google-earth-ec-stable-7.3.7.1094-0.x86_64 does not verify: no digest Google Earth Pro gives the same error... dnf install google-earth-pro-stable Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Installing: google-earth-pro-stable x86_64 7.3.7.1094-0 google-earth 244.4 MiB Transaction Summary: Installing: 1 package Total size of inbound packages is 74 MiB. Need to download 74 MiB. After this operation, 244 MiB extra will be used (install 244 MiB, remove 0 B). Is this ok [y/N]: y [1/1] google-earth-pro-stable-0:7.3.7.1 100% | 4.0 MiB/s | 73.9 MiB | 00m19s -------------------------------------------------------------------------------- [1/1] Total 100% | 4.0 MiB/s | 73.9 MiB | 00m19s Running transaction Transaction failed: Rpm transaction failed. - package google-earth-pro-stable-7.3.7.1094-0.x86_64 does not verify: no digest Installing manually, using, rpm -Uvh --nodigest /var/cache/libdnf5/google-earth-17f28a61f303b7a2/packages/google-earth-ec-stable-7.3.7.1094-0.x86_64.rpm is a workaround, but not really that useful in an automated world. Especially when the failure of that package causes nothing else queued for installation by dnf in that automatic transaction to be installed. Here is the result of, # rpm -qi /var/cache/libdnf5/google-earth-17f28a61f303b7a2/packages/google-earth-ec-stable-7.3.7.1094-0.x86_64.rpm Name : google-earth-ec-stable Version : 7.3.7.1094 Release : 0 Architecture: x86_64 Install Date: (not installed) Group : Applications/Internet Size : 256279513 License : Multiple, see http://www.google.com/earth Signature : RSA/SHA512, Thu 05 Feb 2026 09:56:55, Key ID 32ee5355a6bc6e42 RSA/SHA512, Thu 05 Feb 2026 09:56:55, Key ID 32ee5355a6bc6e42 Source RPM : google-earth-ec-stable-7.3.7.1094-0.src.rpm Build Date : Thu 05 Feb 2026 09:46:22 Build Host : 2073fa655d64 Relocations : /opt Packager : Google Earth Team <google-earth-support> 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. Further, To quote "Jef Spaleta jspaleta Fedora Project Leader" in, https://discussion.fedoraproject.org/t/cannot-install-google-earth-pro-on-fedora-43-does-not-verify-no-digest/181852/10 --------------------------------------------------------------------------------- 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. -------------------------------------------------------------------------------- Hence I am reporting this here as it seems not to have been... Delicate problem obviously.
Thanks for the details. I think first flaw is here: > /etc/yum.repos.d/google-earth-ec.repo : > [google-earth-ec] > name=google-earth-ec > baseurl=http://dl.google.com/linux/earth/rpm/stable/x86_64 > enabled=1 > gpgcheck=1 > The repository is missing gpgkey option. Without it DNF cannot know where from to download the missing keys. I believe that if you add the correct gpgkey option and delete all Google's keys from RPM key store (because the expire plugin does not handle subkeys correctly), DNF will attempt to import the new key. Please try that. > 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. I don't think it has anything to with RPM formats. I think it's more about Google trying to do its own key management using RPM script lets which fail because you cannot modify RPM key store while another RPM transaction is running. > 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 certainly has. E.g. dnf5 has "tsflags" option with "nocrypto" value which does exactly that.
Tried, failed UNLESS I use --nodigest & do it manually. The repo file installed with that version of googleearth is... /etc/yum.repos.d/google-earth-ec.repo : [google-earth-ec] name=google-earth-ec baseurl=http://dl.google.com/linux/earth/rpm/stable/x86_64 enabled=1 gpgcheck=0 ie. no gpgkey option & that's turned off but then subsequent installs fail with... does not verify: no digest Why do you think the problem is NOT "nodigest"???
rpm -K /var/cache/libdnf5/google-earth-17f28a61f303b7a2/packages/google-earth-ec-stable-7.3.7.1094-0.x86_64.rpm /var/cache/libdnf5/google-earth-17f28a61f303b7a2/packages/google-earth-ec-stable-7.3.7.1094-0.x86_64.rpm: DIGESTS signatures NOT OK It does not matter what I do with gpgcheck etc. The song remains the same - sorry Led Zeppelin - I mean the error remains the same.
Now I can see it. I thought that "dnf5 --setopot tsflags=nocrypto" skips digest verification because it sets RPMVSF_MASK_NODIGESTS bit in RPM transaction flags, but it obviously is not enough. RPM library has independent settings for verification and for policing. DNF5 should set RPMTRANS_FLAG_NOFILEDIGEST at more places. Probably in libdnf5::rpm::Transaction::ts_change_callback(), where it hard-codes RPMSIG_DIGEST_TYPE now, it should respect tsflags=nocrypto option. In the mean time, you can work around it on RPM level by adding "%_pkgverify_level none" line into an RPM configuration file, e.g. into any file matching /etc/rpm/macros.* glob. But still Google should produce Fedora packages which pass checks in default Fedora security settings.
Isn't that exactly what "Jef Spaleta jspaleta Fedora Project Leader" in, https://discussion.fedoraproject.org/t/cannot-install-google-earth-pro-on-fedora-43-does-not-verify-no-digest/181852/10 was saying? Yes, on the google front, BUT, this was obviously precipitated by a change in how dnf5/rpm interact. So hopefully it will be resolved with a "WARNING" rather than failure in future. At least for a while...
It's nice that my instincts about these sort of problems are still good. But its not important. What is important are the following questions. Is this an established regression? And if so is this something that can get fixed in an F43 update? Looking forward to F44 is this something that needs to be noted in the release notes for people who move from F42 directly to F44? or is this going to get addressed in time for F44?
> Is this an established regression? I believe it isn't because fedora's librpm has required valid checksums for ages. But I did not tested it. > And if so is this something that can get fixed in an F43 update? It can be fixed, but it has low priority. > Looking forward to F44 is this something that needs to be noted in the release notes for people who move from F42 directly to F44? This the same as your first question. I'm not sure whether Fedora should document how to install proprietary software from a broken package. > or is this going to get addressed in time for F44? That same answer as for F43.
mmmm regression testing... I've been transported back to the 1970's when I was using with PDP11s, HP2100s & 21MX & I had to do the "testing" 'cos no one else did. Can the google packaging problem be reported without running chrome/google-earth seems not, I must now be in the 60's! Now I know what my Dad really meant when he said "John, I'm just very tired".
I've reported it via the google app feedback. See what happens, I expect it will be misunderstood.
Is there a way to pass --nodigest to the rpm transaction via dnf?
No. You need to configure RPM directly as I already pointed: > In the mean time, you can work around it on RPM level by adding "%_pkgverify_level none" line into an RPM configuration file, e.g. into any file matching /etc/rpm/macros.* glob.
With https://github.com/rpm-software-management/dnf5/pull/2681 patch, `dnf5 --setopt=tsflags=nocrypto` now skips also digest checks correctly and allow v3 packages to be installed.
When will this patch make it into FC43? Earlier I asked... Is there a way to pass --nodigest to the rpm transaction via dnf? Petr Pisar said... No. You need to configure RPM directly as I already pointed: Obviously something like that is needed! Having dnf update fail like this means that this change to dnf that caused the failure (of one package) results in potential security problems because other packages fail to update. Seems to me fixing this is an urgent security problem for dnf. That is not fixed by having a patch! There must currently be a lot of FC43 implementations that are suffering this & the user does not understand why their updates are failing. ie. It does not resolve this bug for the majority of users!!!
FEDORA-2026-7f8c20f800 (dnf5-5.4.1.0-1.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f8c20f800
FEDORA-2026-7f8c20f800 has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-7f8c20f800` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-7f8c20f800 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-e62b1e891a (dnf5-5.2.18.0-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-e62b1e891a
FEDORA-2026-e62b1e891a has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-e62b1e891a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-e62b1e891a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-e62b1e891a (dnf5-5.2.18.0-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-7f8c20f800 (dnf5-5.4.1.0-1.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Fedora Update System from comment #20) > FEDORA-2026-e62b1e891a (dnf5-5.2.18.0-3.fc43) has been pushed to the Fedora > 43 stable repository. > If problem still persists, please make note of it in this bug report. Begging everyone's pardon, but the suggested command line does not work for me after the update to dnf5-5.2.18.0-3.fc43.x86_64: # dnf5 --setopt tsflags=nocrypto install google-earth-pro-stable Updating and loading repositories: Repositories loaded. Package Arch Version Repository Size Installing: google-earth-pro-stable x86_64 7.3.7.1155-0 google-earth-pro 244.4 MiB Transaction Summary: Installing: 1 package Total size of inbound packages is 74 MiB. Need to download 74 MiB. After this operation, 244 MiB extra will be used (install 244 MiB, remove 0 B). Is this ok [y/N]: y [1/1] google-earth-pro-stable-0:7.3.7.1155-0.x86_64 100% | 18.1 MiB/s | 73.9 MiB | 00m04s -------------------------------------------------------------------------------------------------------------------------- [1/1] Total 100% | 18.1 MiB/s | 73.9 MiB | 00m04s Running transaction Transaction failed: Rpm transaction failed. - package google-earth-pro-stable-7.3.7.1155-0.x86_64 does not verify: no digest # rpm -q dnf5 dnf5-5.2.18.0-3.fc43.x86_64
(In reply to Stan King from comment #22) The transaction flag needs to be set in conjunction with --nogpgcheck in order to function, see https://github.com/rpm-software-management/dnf5/commit/57263d0ac3b34fa32c94e6e2be127027abbaa4c1
(In reply to Elliott Tallis from comment #23) > (In reply to Stan King from comment #22) > The transaction flag needs to be set in conjunction with --nogpgcheck in > order to function, see > https://github.com/rpm-software-management/dnf5/commit/ > 57263d0ac3b34fa32c94e6e2be127027abbaa4c1 I set gpgcheck=0 in the repo definition file, and then it worked. Thanks.
And so, Manual update/install will always be required for these packages into the future? UNLESS google include the digest, or build with updated rpmbuild?
Yes. Though you can permanently set the tsflags option in /etc/dnf/dnf.conf.
But then that flag applies to ALL transactions, not just the one we need it for.