Improve the error msg for target rpms with RSA/SHA1 signature

[nicrame]

Actual behavior
I'm trying to upgrade RHEL 8.6 to 9. While preupgrade goes fine, the real upgrade fail with error below.

To Reproduce
Run leapp upgrade --debug --target 9.0
Result:

STDERR:
warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
Warning: Package marked by Leapp to upgrade not found in repositories metadata: leapp leapp-upgrade-el8toel9 gpg-pubkey python3-leapp
warning: Found bdb_ro Packages database while attempting sqlite backend: using bdb_ro backend.
error: rpmdbNextIterator: skipping h#    1493
Header V4 RSA/SHA1 Signature, key ID 764429e6: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
error: rpmdbNextIterator: skipping h#    1493
Header V4 RSA/SHA1 Signature, key ID 764429e6: BAD
Header SHA256 digest: OK
Header SHA1 digest: OK
Error: An rpm exception occurred: package not installed


============================================================
                       END OF ERRORS
============================================================

2022-07-11 19:55:20.774 WARNING  PID: 37337 leapp.reporting: Stable Key report entry not provided, dynamically generating one - 84f6134080970e5a7dee04dac3827a6fabb06a93
2022-07-11 19:55:20.783 WARNING  PID: 37337 leapp.reporting: Stable Key report entry not provided, dynamically generating one - 84f6134080970e5a7dee04dac3827a6fabb06a93

Debug output written to /var/log/leapp/leapp-upgrade.log

============================================================
                           REPORT
============================================================

A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                       END OF REPORT
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

Expected behavior
Edited(@pirat89):
Upgrade OS.
Update the error msg to make clear what's exactly the problem and what people could do.

System information (please complete the following information):
Red Hat Enterprise Linux 8.6 (Ootpa)

• # uname -a
• Linux Love-NAS 4.18.0-372.13.1.el8_6.x86_64 Add README and initial Cockpit plugin leapp#1 SMP Mon Jun 6 15:05:22 EDT 2022 x86_64 x86_64 x86_64 GNU/Linux
• # rpm -qa "*leapp*" (or shorthashes of commits in case of manual installation):
• leapp-0.14.0-1.el8_6.noarch
• cockpit-leapp-0.1.6-5.el8_6.noarch
• python3-leapp-0.14.0-1.el8_6.noarch
• leapp-deps-0.14.0-1.el8_6.noarch
• leapp-upgrade-el8toel9-0.16.0-6.el8_6.noarch
• leapp-upgrade-el8toel9-deps-0.16.0-6.el8_6.noarch

Attach (or provide link to) log files if applicable (optional - may contain confidential information):
https://love.itos.pl/s/y8TSYnY8jiggz8X

Additional context
I already tried rebuilding rpm db with "rpm --rebuilddb" and "dcrpm" but it looks fine.

[pirat89]

@nicrame Hi. This cannot be actually fixed on our side now. The error you see is caused by an rpm that is going to be installed on the system during the upgrade - to be clear, the package is signed by depracated algorithms (SHA1). We cannot check the signature of the package before it is downloaded. The download of packages is happening AFTER reporting phase, which means after the preupgrade ends, as the download of packages could be considerably time-consuming for people. We are thinking about a way to cover these later phases in future as well by preupgrade sub-command (possibly with some special option?). But it will not happen in a close future.

To better understand the problem, see:

• https://access.redhat.com/solutions/6868611
• https://access.redhat.com/articles/6846411

[nicrame]

Oh, thank You for explanation. Maybe when there is such problem, it would be nice to make information below STDERR to be more simple and understandable for human forms, or give some clue what is happening, because to say the truth, it was completely no information for me at all what is wrong, why, and how to resolve this.

[pirat89]

You are right. We plan to cover it in future by a better error msg. Regarding the missing time we considered this as minor issue in the past as system is not harmed and we expected that when people deliver some rpms with RSA/SHA1 signature to be installed during the upgrade, such a packages will be already present on the system, which we covered by inhibitor with proper instructions. Hopefully we will cover better err msg for the next release.

[pirat89]

@nicrame just for the curiosity. Have you had some packages with RSA/SHA1 signatures installed on the system before already or packages with the problematic signatures have been discovered just in custom repos related to RHEL 9?

[nicrame]

@nicrame just for the curiosity. Have you had some packages with RSA/SHA1 signatures installed on the system before already or packages with the problematic signatures have been discovered just in custom repos related to RHEL 9?

They were already there. Some (few) packages were installed from additional repo that i used when i played with "ovirt" install. I have removed ovirt and just used kvm, but some repo was still there, and it was interesting because few libs and python3-something packages were in newer versions from that ovirt repo that i had. My solution was to downgrade those packages.
I just do the trick with:
rpm -q --nosignature --querybynumber XXX
dnf --showduplicates list python3-cairo
dnf downgrade python3-cairo-1.16.3-6.el8

After few times i just "dnf list installed | grep @ovirt-4.4" and downgrade every packages, then removed this repo, and then update did go fine, and i've got updated OS!

[pirat89]

@nicrame Just checked the logs seeing that you already have present problematic packages on the system as mentioned in the report file

Risk Factor: high
Title: Detected RPMs with RSA/SHA1 signature
Summary: Digital signatures using SHA-1 hash algorithm are no longer considered secure and are not allowed to be used on RHEL 9 systems by default. This causes issues when using DNF/RPM to handle packages with RSA/SHA1 signatures as the signature cannot be checked with the default cryptographic policy. Any such packages cannot be installed, removed, or replaced unless the signature check is disabled in dnf/rpm or SHA-1 is enabled using non-default crypto-policies. For more information see the following documents:
....

But what is important, this report is not inhibitor. So I assume you have set already the LEGACY system wide crypto policies, correct? (I would check that but in the attached files I can access only text files; binary files return 502 gateway err). If so, the error is weird as you should be able to upgrade then. We have been using it as a workaround in the past for couple of months and it worked pretty well, so I am confused why it's not working in your case now. But I've seen similar problem on a cloud machine yesterday. I already planed to investigate that later this / the other week. So if we discover what's wrong, we will let you know here. From our POV, when you set the LEGACY crypto policies (reboot expected after that) you should be able to upgrade even with such a packages.

[praiskup]

it was interesting because few libs and python3-something packages were in newer versions from that ovirt repo that i had

If the external repo is hosted in Fedora Copr, this SHA mixup is expected. We used the default (SHA1) algorithm for signing packages in Copr and switched to SHA256 recently.