Immediately after an install from a verified ISO of CentOS 8.0.1905, I logged on as root, enabled the network, logged off; logged in as the user created in installation, and and ran sudo yum update. No plugins are loaded.
Many many errors followed regarding the GPG key, so I ran sudo yum clean all , sudo yum clean metadata , and dnf clean all then ran sudo yum update again with the same failure
Have not created local copies of packages or used a local repo which eliminates yum update on CentOS 6.6 fails
/etc/yum/pluginconf.d/fastestmirror.conf was empty which would seem to negate CentOs 5.3, Yum Update Fails as a source of solutions.
Another affected user here, but just to add to @hbjydev’s comment about updating crypto policies, SHA1 can be disabled after install like this
update-crypto-policies --set DEFAULT:NO-SHA1It certainly could be, but I don’t think it’s wise until they fix the package signatures, because doing this will just break any updates to the package until it’s sorted out at the repo end.
For a dev or test box, sure, but I can’t recommend if you’re in production.
I’m not sure anyone is using CentOS 9 Stream in production, however RHEL 9 went GA last week so it won’t be long before it starts making its way into prod environments and as this issue also affects RHEL 9 people are going to be eager to test things out, I’m already doing test deployments on RHEL 9 which other than the SHA1 issue and another minor issue not directly related to k3s has gone rather well so far.
The problem here is as far back as 2005 SHA-1 was considered not secure, so its kind of surprising to see a project in 2022 still signing packages with SHA-1. Collision attacks on SHA-1 are feasible in 2022, there’s an interesting answer posted to stackexchange that calculates the time required for a successful attack using current generation GPU’s, and before anyone scoff’s at the costs of running multiple high end GPU’s consider that crypto miners are running small farms with enough RTX30xx’s and/or RX 6×00’s to generate successful attacks in a few months from their own homes.
Please don’t take this as a personal attack, its not, I do understand that things get overlooked sometimes.
Skip to content
Sometimes you might need to install a RPM package individually on a system. You donwload it from a trusted repository and use yum (dnf) to install it locally — simple enough.
However with a secured system, you might run into some issues.
— GPG check FAILED
Downloading Packages:
Package managesoft-13.1.1-1.x86_64.rpm is not signed
Error: GPG check FAILEDThat usually means the RPM package is not GPG signed or something wrong with the GPG signature. You can check the GPG signature of a RPM package:
root@joelinux:~# rpm -K managesoft-13.1.1-1.x86_64.rpm
managesoft-13.1.1-1.x86_64.rpm: digests OKIf you see the GPG signature seems to be good and the RPM is truthworthy. You can just use “–nogpgcheck” of yum to skip this check.
root@joelinux:~# yum --nogpgcheck localinstall managesoft-13.1.1-1.x86_64.rpm— package does not verify: no digest
Again, yum cannot verify or doesn’t find digest of the RPM package. One way to work around is to use the rpm command to install because it has an option “–nodiegest”
rpm -ivh --nodigest --nofiledigest /tmp/managesoft-13.1.1-1.x86_64.rpmOr for Redhat Linux 7 or 8, disable FIPS if that’s not needed in your environment:
root@joelinux:~# /usr/bin/fips-mode-setup --disable
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be disabled.
Please reboot the system for the setting to take effect.
root@joelinux:~# /usr/bin/fips-mode-setup --check
FIPS mode is disabled.Once FIPS is disabled and the system is rebooted, you should be able to install it with yum:
yum --nogpgcheck localinstall managesoft-13.1.1-1.x86_64.rpm
The Problem
DNF Update fails with the below error:
2018-06-22T14:31:22 DDEBUG Cleaning up.
2018-06-22T14:31:22 INFO The downloaded packages were saved in cache until the next successful transaction.
2018-06-22T14:31:22 INFO You can remove cached packages by executing 'dnf clean packages'.
2018-06-22T14:31:22 SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 168, in resolving
base.do_transaction(display=displays)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 232, in do_transaction
self.gpgsigcheck(install_pkgs)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 295, in gpgsigcheck
raise dnf.exceptions.Error(_("GPG check FAILED"))
dnf.exceptions.Error: GPG check FAILED
2018-06-22T14:31:22Z CRITICAL Error: GPG check FAILED
The Solution
If you are using “dnf config-manager –add-repo” to add a repository, the command does not add the GPG key file location configuration for that repository. A package installation would fail, as by default, dnf enables gpgcheck. It equires the GPG key to be set or imported.
1. Manually set and import the GPG key file location:
# rpm --import "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle"
or
2. Add or set the GPG key for all of the individual repository entries under /etc/yum.repos.d:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
Перейти к контенту
Immediately after an install from a verified ISO of CentOS 8.0.1905, I logged on as root, enabled the network, logged off; logged in as the user created in installation, and and ran sudo yum update. No plugins are loaded.
Many many errors followed regarding the GPG key, so I ran sudo yum clean all , sudo yum clean metadata , and dnf clean all then ran sudo yum update again with the same failure
Have not created local copies of packages or used a local repo which eliminates yum update on CentOS 6.6 fails
/etc/yum/pluginconf.d/fastestmirror.conf was empty which would seem to negate CentOs 5.3, Yum Update Fails as a source of solutions.
Paulo Tomé
3,7145 gold badges25 silver badges37 bronze badges
asked Dec 27, 2019 at 18:48
2
Since the error discussed a GPG key, renamed the two GPG keys in /etc/pki/rpm-gpg/ to add .bad at the end, hoping to get a new GPG key.
Repeated sudo yum clean all , sudo yum clean metadata , and dnf clean all , then ran sudo yum update again and it tells me it can’t open /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
Renamed the keys by removing the .bad suffix. Reran sudo yum update and was prompted to accept the keys. I did, and the update succeeded.
answered Dec 27, 2019 at 18:50
K7AAYK7AAY
3,6203 gold badges22 silver badges39 bronze badges
I ran
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
then reran sudo yum update.
Stephen Kitt
395k53 gold badges1016 silver badges1119 bronze badges
answered Sep 29, 2020 at 15:02
idereidere
111 bronze badge
Skip to content
Sometimes you might need to install a RPM package individually on a system. You donwload it from a trusted repository and use yum (dnf) to install it locally — simple enough.
However with a secured system, you might run into some issues.
— GPG check FAILED
Downloading Packages:
Package managesoft-13.1.1-1.x86_64.rpm is not signed
Error: GPG check FAILEDThat usually means the RPM package is not GPG signed or something wrong with the GPG signature. You can check the GPG signature of a RPM package:
root@joelinux:~# rpm -K managesoft-13.1.1-1.x86_64.rpm
managesoft-13.1.1-1.x86_64.rpm: digests OKIf you see the GPG signature seems to be good and the RPM is truthworthy. You can just use “–nogpgcheck” of yum to skip this check.
root@joelinux:~# yum --nogpgcheck localinstall managesoft-13.1.1-1.x86_64.rpm— package does not verify: no digest
Again, yum cannot verify or doesn’t find digest of the RPM package. One way to work around is to use the rpm command to install because it has an option “–nodiegest”
rpm -ivh --nodigest --nofiledigest /tmp/managesoft-13.1.1-1.x86_64.rpmOr for Redhat Linux 7 or 8, disable FIPS if that’s not needed in your environment:
root@joelinux:~# /usr/bin/fips-mode-setup --disable
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be disabled.
Please reboot the system for the setting to take effect.
root@joelinux:~# /usr/bin/fips-mode-setup --check
FIPS mode is disabled.Once FIPS is disabled and the system is rebooted, you should be able to install it with yum:
yum --nogpgcheck localinstall managesoft-13.1.1-1.x86_64.rpm-
svennd
- Posts: 45
- Joined: 2015/12/11 10:25:22
- Contact:
GPG check Failed
I installed a fresh Centos 8 system, and wanted to update; but the GPG check failed; I can obv. ignore this, but I’m not sure that’s the best idea…
Any idea what I did wrong ? I checked network and that seems to work fine.
Code: Select all
# dnf update
CentOS-8 - AppStream 62 kB/s | 4.3 kB 00:00
CentOS-8 - Base 13 kB/s | 3.9 kB 00:00
CentOS-8 - Extras 19 kB/s | 1.5 kB 00:00
Dependencies resolved.
===========================================================================================
Package Arch Version Repository Size
===========================================================================================
Installing:
kernel x86_64 4.18.0-80.11.2.el8_0 BaseOS 424 k
kernel-core x86_64 4.18.0-80.11.2.el8_0 BaseOS 24 M
kernel-modules x86_64 4.18.0-80.11.2.el8_0 BaseOS 20 M
Upgrading:
bind-libs x86_64 32:9.11.4-17.P2.el8_0.1 AppStream 169 k
[...]
systemd-udev x86_64 239-13.el8_0.5 BaseOS 1.3 M
vdo x86_64 6.2.0.298-10.el8_0 BaseOS 682 k
Installing dependencies:
grub2-tools-efi x86_64 1:2.02-66.el8_0.1 BaseOS 444 k
Transaction Summary
===========================================================================================
Install 4 Packages
Upgrade 84 Packages
Total size: 104 M
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] grub2-tools-efi-2.02-66.el8_0.1.x86_64.rpm: Already downloaded
[...]
[SKIPPED] vdo-6.2.0.298-10.el8_0.x86_64.rpm: Already downloaded
warning: /var/cache/dnf/BaseOS-929b586ef1f72f69/packages/grub2-tools-efi-2.02-66.el8_0.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 8483c65d: NOKEY
CentOS-8 - Base 1.6 MB/s | 1.6 kB 00:00
CentOS-8 - AppStream 1.6 MB/s | 1.6 kB 00:00
The GPG keys listed for the "CentOS-8 - Base" 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: grub2-tools-efi-1:2.02-66.el8_0.1.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
Public key for kernel-4.18.0-80.11.2.el8_0.x86_64.rpm is not installed. Failing package is: kernel-4.18.0-80.11.2.el8_0.x86_64
[...]
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
Public key for vdo-6.2.0.298-10.el8_0.x86_64.rpm is not installed. Failing package is: vdo-6.2.0.298-10.el8_0.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
-
TrevorH
- Site Admin
- Posts: 32657
- Joined: 2009/09/24 10:40:56
- Location: Brighton, UK
Re: GPG check Failed
Post
by TrevorH » 2019/11/21 11:35:43
That says that grub2-tools-efi-2.02-66.el8_0.1.x86_64.rpm is signed with key ID 8483c65d and that is indeed correct.
What is the output from rpm -qa gpg-pubkey* ? Is gpg-pubkey-8483c65d-5ccc5b19 listed there? What does rpm -qi gpg-pubkey-8483c65d-5ccc5b19 say?
-
svennd
- Posts: 45
- Joined: 2015/12/11 10:25:22
- Contact:
Re: GPG check Failed
Post
by svennd » 2019/11/21 11:47:05
Code: Select all
[root@prom1 ~]# rpm -qa gpg-pubkey*
[root@prom1 ~]# rpm -qi gpg-pubkey-8483c65d-5ccc5b19
package gpg-pubkey-8483c65d-5ccc5b19 is not installed
Aha; Guess you found the issue; On the second machine working machine I get :
Code: Select all
[root@prom1b ~]# rpm -qa gpg-pubkey*
gpg-pubkey-8483c65d-5ccc5b19
[root@prom1b ~]# rpm -qi gpg-pubkey-8483c65d-5ccc5b19
Name : gpg-pubkey
Version : 8483c65d
Release : 5ccc5b19
Architecture: (none)
Install Date: Wed 20 Nov 2019 01:39:37 PM CET
Group : Public Keys
Size : 0
License : pubkey
Signature : (none)
Source RPM : (none)
Build Date : Fri 03 May 2019 05:15:37 PM CEST
Build Host : localhost
Relocations : (not relocatable)
Packager : CentOS (CentOS Official Signing Key) <security@centos.org>
Summary : gpg(CentOS (CentOS Official Signing Key) <security@centos.org>)
Description :
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: rpm-4.14.2 (NSS-3)
mQINBFzMWxkBEADHrskpBgN9OphmhRkc7P/YrsAGSvvl7kfu+e9KAaU6f5MeAVyn
rIoM43syyGkgFyWgjZM8/rur7EMPY2yt+2q/1ZfLVCRn9856JqTIq0XRpDUe4nKQ
8BlA7wDVZoSDxUZkSuTIyExbDf0cpw89Tcf62Mxmi8jh74vRlPy1PgjWL5494b3X
5fxDidH4bqPZyxTBqPrUFuo+EfUVEqiGF94Ppq6ZUvrBGOVo1V1+Ifm9CGEK597c
aevcGc1RFlgxIgN84UpuDjPR9/zSndwJ7XsXYvZ6HXcKGagRKsfYDWGPkA5cOL/e
f+yObOnC43yPUvpggQ4KaNJ6+SMTZOKikM8yciyBwLqwrjo8FlJgkv8Vfag/2UR7
JINbyqHHoLUhQ2m6HXSwK4YjtwidF9EUkaBZWrrskYR3IRZLXlWqeOi/+ezYOW0m
vufrkcvsh+TKlVVnuwmEPjJ8mwUSpsLdfPJo1DHsd8FS03SCKPaXFdD7ePfEjiYk
nHpQaKE01aWVSLUiygn7F7rYemGqV9Vt7tBw5pz0vqSC72a5E3zFzIIuHx6aANry
Gat3aqU3qtBXOrA/dPkX9cWE+UR5wo/A2UdKJZLlGhM2WRJ3ltmGT48V9CeS6N9Y
m4CKdzvg7EWjlTlFrd/8WJ2KoqOE9leDPeXRPncubJfJ6LLIHyG09h9kKQARAQAB
tDpDZW50T1MgKENlbnRPUyBPZmZpY2lhbCBTaWduaW5nIEtleSkgPHNlY3VyaXR5
QGNlbnRvcy5vcmc+iQI3BBMBAgAhBQJczFsZAhsDBgsJCAcDAgYVCAIJCgsDFgIB
Ah4BAheAAAoJEAW1VbOEg8ZdjOsP/2ygSxH9jqffOU9SKyJDlraL2gIutqZ3B8pl
Gy/Qnb9QD1EJVb4ZxOEhcY2W9VJfIpnf3yBuAto7zvKe/G1nxH4Bt6WTJQCkUjcs
N3qPWsx1VslsAEz7bXGiHym6Ay4xF28bQ9XYIokIQXd0T2rD3/lNGxNtORZ2bKjD
vOzYzvh2idUIY1DgGWJ11gtHFIA9CvHcW+SMPEhkcKZJAO51ayFBqTSSpiorVwTq
a0cB+cgmCQOI4/MY+kIvzoexfG7xhkUqe0wxmph9RQQxlTbNQDCdaxSgwbF2T+gw
byaDvkS4xtR6Soj7BKjKAmcnf5fn4C5Or0KLUqMzBtDMbfQQihn62iZJN6ZZ/4dg
q4HTqyVpyuzMXsFpJ9L/FqH2DJ4exGGpBv00ba/Zauy7GsqOc5PnNBsYaHCply0X
407DRx51t9YwYI/ttValuehq9+gRJpOTTKp6AjZn/a5Yt3h6jDgpNfM/EyLFIY9z
V6CXqQQ/8JRvaik/JsGCf+eeLZOw4koIjZGEAg04iuyNTjhx0e/QHEVcYAqNLhXG
rCTTbCn3NSUO9qxEXC+K/1m1kaXoCGA0UWlVGZ1JSifbbMx0yxq/brpEZPUYm+32
o8XfbocBWljFUJ+6aljTvZ3LQLKTSPW7TFO+GXycAOmCGhlXh2tlc6iTc41PACqy
yy+mHmSv
=kkH7
-----END PGP PUBLIC KEY BLOCK-----
now how to fix it 
-
TrevorH
- Site Admin
- Posts: 32657
- Joined: 2009/09/24 10:40:56
- Location: Brighton, UK
Re: GPG check Failed
Post
by TrevorH » 2019/11/21 14:16:28
rpm —import /etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
-
svennd
- Posts: 45
- Joined: 2015/12/11 10:25:22
- Contact:
Re: GPG check Failed
Post
by svennd » 2019/11/21 14:41:56
Oké, I kinda feel stupid now. How could this happen ?
Thanks for the help !
Another affected user here, but just to add to @hbjydev’s comment about updating crypto policies, SHA1 can be disabled after install like this
update-crypto-policies --set DEFAULT:NO-SHA1It certainly could be, but I don’t think it’s wise until they fix the package signatures, because doing this will just break any updates to the package until it’s sorted out at the repo end.
For a dev or test box, sure, but I can’t recommend if you’re in production.
I’m not sure anyone is using CentOS 9 Stream in production, however RHEL 9 went GA last week so it won’t be long before it starts making its way into prod environments and as this issue also affects RHEL 9 people are going to be eager to test things out, I’m already doing test deployments on RHEL 9 which other than the SHA1 issue and another minor issue not directly related to k3s has gone rather well so far.
The problem here is as far back as 2005 SHA-1 was considered not secure, so its kind of surprising to see a project in 2022 still signing packages with SHA-1. Collision attacks on SHA-1 are feasible in 2022, there’s an interesting answer posted to stackexchange that calculates the time required for a successful attack using current generation GPU’s, and before anyone scoff’s at the costs of running multiple high end GPU’s consider that crypto miners are running small farms with enough RTX30xx’s and/or RX 6×00’s to generate successful attacks in a few months from their own homes.
Please don’t take this as a personal attack, its not, I do understand that things get overlooked sometimes.
The Problem
DNF Update fails with the below error:
2018-06-22T14:31:22 DDEBUG Cleaning up.
2018-06-22T14:31:22 INFO The downloaded packages were saved in cache until the next successful transaction.
2018-06-22T14:31:22 INFO You can remove cached packages by executing 'dnf clean packages'.
2018-06-22T14:31:22 SUBDEBUG
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 64, in main
return _main(base, args, cli_class, option_parser_class)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 99, in _main
return cli_run(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 123, in cli_run
ret = resolving(cli, base)
File "/usr/lib/python3.6/site-packages/dnf/cli/main.py", line 168, in resolving
base.do_transaction(display=displays)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 232, in do_transaction
self.gpgsigcheck(install_pkgs)
File "/usr/lib/python3.6/site-packages/dnf/cli/cli.py", line 295, in gpgsigcheck
raise dnf.exceptions.Error(_("GPG check FAILED"))
dnf.exceptions.Error: GPG check FAILED
2018-06-22T14:31:22Z CRITICAL Error: GPG check FAILED
The Solution
If you are using “dnf config-manager –add-repo” to add a repository, the command does not add the GPG key file location configuration for that repository. A package installation would fail, as by default, dnf enables gpgcheck. It equires the GPG key to be set or imported.
1. Manually set and import the GPG key file location:
# rpm --import "file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle"
or
2. Add or set the GPG key for all of the individual repository entries under /etc/yum.repos.d:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle