can't rpm erase, package with invalid hash lodged inside rpmdb

[hgkamath]

Description

rpm query commands on invocation show annoying/distracting hash/digest errors.

When using rpm I think there are two non-easily identifiable packages are messed up.
The rpm -e erase option does not have a --nodigest argument unlike the install/upgrade/verify options.
The below logs show that unnamed packages through up hashdigest errors.
From the key signature a109b1ec I deduced the packages to be livna-release and libdvdcss.

I recently did an upgrade from fedora-37 to fedora-38,
For the most part, other than a few dependency hiccups with some packages like ffmpeg-libs, libplacebo, libchromapaint, which were resolved, the update went smoothly. Fedora-38 boots and works with no issues.

• So my question is, how can I fix this?
  Attempting to force install livna-release is also not possible
  I have tried moving out the gpgkeys manually from /etc/pki and /etc/yum.repos.d, no effect.

Logs

[root@sirius livna]# rpm -qa > /dev/null # just to see the stderr
error: rpmdbNextIterator: skipping h#      17 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h#      19 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK

[root@sirius livna]#  rpm -e livna-release
error: rpmdbNextIterator: skipping h#      17 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK

[root@sirius livna]#  rpm -e libdvdcss
error: rpmdbNextIterator: skipping h#      19 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK

[root@sirius livna]# rpm -e livna-release --nodeps --justdb
error: rpmdbNextIterator: skipping h#      17 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK


[root@sirius livna]# rpm -i ./livna-release-1-1.noarch.rpm
error: ./livna-release-1-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
error: ./livna-release-1-1.noarch.rpm cannot be installed

[root@sirius livna]# rpm -i ./livna-release-1-1.noarch.rpm --force
error: ./livna-release-1-1.noarch.rpm: Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
error: ./livna-release-1-1.noarch.rpm cannot be installed

[root@sirius livna]# rpm -qa | grep -Ei "^rpm-4|rpm-l"
error: rpmdbNextIterator: skipping h#      17 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h#      19 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK
rpm-libs-4.18.1-1.fc38.x86_64
rpm-4.18.1-1.fc38.x86_64

[root@sirius livna]# uname -a
Linux sirius 6.2.8-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 22 19:29:30 UTC 2023 x86_64 GNU/Linux

[root@sirius livna]# cat /etc/os-release | grep -E "^NAME=|^VERSION="
NAME="Fedora Linux"
VERSION="38 (Workstation Edition Prerelease)"

Ref

• corresponding buzilla bug https://bugzilla.redhat.com/show_bug.cgi?id=2183489

[pmatilai]

This is a Fedora matter, see https://bugzilla.redhat.com/show_bug.cgi?id=2170878 for details.

[voxik]

I just wonder, what benefit it has to check some signature for uninstallation? The package needed to be installed somehow, it was trusted once, it is recoded in rpmdb. So why it can't be removed?

[hgkamath]

In the man rpm, a possible man-page bug :
The --nosignature is listed under sections § INSTALL & UPGRADE OPTIONS and § VERIFY OPTIONS.
The --querybynumber is listed under § select-options/PACKAGE SELECTION OPTIONS.
Section § Erase Options does not list --nosignature as an argument.

It is a little non-obvious, but the composition works (suggested in links given below)

[root@sirius livna]# rpm -q --nosignature --querybynumber 17
livna-release-1-1.noarch
[root@sirius livna]# rpm -e --nosignature livna-release-1-1.noarch
[root@sirius livna]# 

It is nice to be able to do

rpm -e <package> --nosignature

The argument --nosignature is passed and recognized and seems to work.
Test on another non-problem package:

[root@sirius livna]# rpm -e mplayer --nosignaturex
rpm: --nosignaturex: unknown option
[root@sirius livna]# rpm -e mplayer --nosignature
[root@sirius livna]# 

So if it is the case that --nosignature can be used for rpm --erase then the man page needs to specify that in some section.
a) Is it (--nosignature) a general selection option that goes into § select-options/PACKAGE SELECTION OPTIONS
b) or should it (--nosignature) be specified as a supported argument in § ERASE OPTIONS

So why it can't be removed?

Perhaps, its useful to not remove easily in a sense that, when the admin doing the uninstalling does so, It is a self-warning that he might not be able to install it back again easily without the proper sufficient-level GPG key.

The below works

[root@sirius livna]# rpm -i ./livna-release-1-1.noarch.rpm --nosignature
[root@sirius livna]# 

and it brings back the hash error message

[root@sirius livna]# rpm -qa >/dev/null
error: rpmdbNextIterator: skipping h#    2828 
Header V4 DSA/SHA1 Signature, key ID a109b1ec: BAD
Header SHA1 digest: OK
[root@sirius livna]# rpm -e livna-release --nosignature
[root@sirius livna]# rpm -qa >/dev/null
[root@sirius livna]# 

If the cryptographic sign checking can be easily bypassed by an admin with --nosignature argument, What good is all the GPG signature if the check can be thus easily bypassed? The only good maybe to hint to the admin that some danger if dealing with a unsigned/improperly-signed package. Maybe, the default in automation scripts is to assume proper signage, and that the gpg check is useful for automated installs/upgrades/removals.

I think the repository package gpg keys are best checked by the software that do download (repo-tools such as dnf) or the rpm argument (-h <url>) . IMHO, the rpm-tools and rpm-database itself does not need to enforce the GPG keys, especially, if the package is already installed. One can also build one's own RPM packages from the SRPMs, such rpm-packages may not always be signed. The command rpm -qa >>/dev/null becomes a quick way to find out if packages installed on the system came from sources that aren't sufficiently well-signed as per present cryptographic policy.

REFS:

• 20230217 Kamil Páral Insecure installed RPMs (like Google Chrome) prevent system updates in F38, can't be removed
  https://bugzilla.redhat.com/show_bug.cgi?id=2170878 :
• 20230230 Kamil Páral Third-party RPMs with an invalid signing key might cause errors during package operations
  https://discussion.fedoraproject.org/t/third-party-rpms-with-an-invalid-signing-key-might-cause-errors-during-package-operations/80077
• 20230227 Kamil Páral Talk: Popular third-party RPMs fail to install/update/remove due to security policies verification
  https://discussion.fedoraproject.org/t/talk-popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70379/1
• 20230208 Kamil Páral Popular third-party RPMs fail to install/update/remove due to security policies verification
  https://discussion.fedoraproject.org/t/popular-third-party-rpms-fail-to-install-update-remove-due-to-security-policies-verification/70498
• 20230330 Rebuild to pull in cryptographic fixes for RPM
  https://bugzilla.redhat.com/show_bug.cgi?id=2183038
• 20230131 Kevin/Nirik error: rpmdbNextIterator: skipping in Fedora 38+
  https://www.scrye.com/wordpress/nirik/2023/01/31/error-rpmdbnextiterator-skipping-in-fedora-38/