Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 2160044

Summary: Regression in rpmdbNextIterator skipping
Product: [Fedora] Fedora Reporter: Zdenek Kabelac <zkabelac>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: ffesti, igor.raits, mdomonko, packaging-team-maint, pmatilai, vmukhame
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-01-11 12:05:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
rpm -qa with embeded stderr none

Description Zdenek Kabelac 2023-01-11 12:00:05 UTC
Created attachment 1937302 [details]
rpm -qa   with  embeded  stderr

Description of problem:

My rawhide distro is continuosly upgrade and maintained system - thus I keep on my system even some older instances of some packages.

With my current version of rpm I'm keep getting these error messages displayed:

error: rpmdbNextIterator: skipping h#      21 
Header V4 RSA/SHA1 Signature, key ID 5ff054bd: BAD
Header SHA1 digest: OK

After trying all the common advices from the net about rebuilding rpm DB and such and gpt chatting :) - I've realized that most likely the cause is in my older installed packages which somehow cannot be processed correctly by current rpm code ??

Not really sure what's going on though - 

Version-Release number of selected component (if applicable):
rpm-4.18.0-8.fc38.x86_64

How reproducible:

i.e. rpm -qa | grep ^rpm-

generates stdout not just with requested result - but also 7 other annoying error message on stderror    (which I could obviously  2>/dev/null) - but I'd rather see properly working rpm.


Expected results:
no errors as the rpm should be backward compatible ???

Additional info:
not sure what could all help to attach.
Packages likely causing these errors are:

recordmydesktop-0.3.8.1-19.fc27.x86_64
cppcheck-1.90-1.kdudka.2.fc33.x86_64

and likely some other - attaching plain  'rpm -qa'

Comment 1 Panu Matilainen 2023-01-11 12:05:39 UTC

*** This bug has been marked as a duplicate of bug 2149762 ***

Comment 2 Zdenek Kabelac 2023-01-11 12:32:07 UTC
Thanks for point out this BZ -  running:  update-crypto-policies --set DEFAULT:SHA1
really fixed the issue on my system (and also allowed to upgrade   google-chrome package)

However I'm finding fiddling with crypto-policies to get error-less report from  rpm kind  user unfriendly way how to deal with this issue.

Maybe 'rpm'  can at least print the error message hinting this  in case it notices this problem  - otherwise users ends with  rebuilding their DB without any success ??

Comment 3 Panu Matilainen 2023-01-11 12:57:29 UTC
A better error message would be nice of course, but rpm doesn't know why it fails. It only knows that a signature check is failing. Signature failures from the rpmdb may indicate tampering. Or not. 

Note that rebuilding the database is just about the last thing you want to do when you get these messages because you'll lose the trace of what was causing it, but leaving the software on the system.

Comment 4 Zdenek Kabelac 2023-01-11 13:01:51 UTC
Well - still it might be 'good' as hint even if the rpm is unaware what is the real cause
(i.e. you report   iterator error with checksum and with first such error - maybe refer the given BZ or something else)

Otherwise - the Google will advice   --rebuilddb - and likely 99.9% will do it first before trying anything else...

Comment 5 Zdenek Kabelac 2023-01-16 17:44:56 UTC
Hmm - interestingly and unsure why -  I had to switch to 'legacy' crypto policy as  default:sha1  was just not working for me properly after next 'dnf update' - with  legacy policy things looks to be working ATM   (not sure if this is bug in update-crypto-policies ATM)

Definitely annoying part - rpm should be able to use for older packages with older keys - noone will be repackaging those. So it really should be an option of rpm  to enable/disable support with 'weak' hash functions.    Downgrading whole system doesn't look like good solution for basic users.

Comment 6 Florian Festi 2023-02-16 08:28:31 UTC
Oh, sorry! Only saw CLOSED DUPLICATE and assumed the needinfo was outdated. Re-adding.

Comment 7 Red Hat Bugzilla 2023-09-19 04:32:27 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days