It was found in RHEL-9.0.0-20220311.d.3.

This is caused when we upgrade openssl from:

working: openssl-libs-3.0.1-7.el9.x86_64
broken:  openssl-libs-3.0.1-15.el9_0.1.x86_64

I will narrow down the exact version later today.  But it seems to
be a bug in openssl / librpm interaction.

Caused by disabling SHA-1 signatures, one of these two changes:

* Tue Feb 22 2022 Dmitry Belyavskiy <dbelyavs> - 1:3.0.1-8
- OpenSSL will generate keys with prime192v1 curve if it is provided using explicit parameters
- Resolves: rhbz#1977867
- pkcs12 export broken in FIPS mode
- Resolves: rhbz#2049265

* Tue Feb 22 2022 Clemens Lang <cllang> - 1:3.0.1-8
- Disable SHA1 signature creation and verification by default
- Set rh-allow-sha1-signatures = yes to re-enable
- Resolves: rhbz#2031742


Please reenable this, we need it for to inspect RPM packages in RHEL 6 guests.

The only change that may cause this result is the switched off support of SHA1 in signatures (see https://bugzilla.redhat.com/show_bug.cgi?id=2058497 for more details).

Don't you use SHA1 in any of GPG keys, for example?

As a temporary measure it may be feasible to switch to LEGACY crypto policy, but the permanent solution requires getting rid of SHA1 signatures.

(In reply to Dmitry Belyavskiy from comment #5)
> As a temporary measure it may be feasible to switch to LEGACY crypto policy,
> but the permanent solution requires getting rid of SHA1 signatures.

It seems the LEGACY setting doesn't work for this case. 

# update-crypto-policies --set LEGACY
Setting system policy to LEGACY
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.
# virt-v2v -i ova centos-Eaton.ova -o null
[   0.0] Setting up the source: -i ova centos-Eaton.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
virt-v2v: warning: could not parse ovf:Name from OVF document
[   2.7] Opening the source
[   7.0] Inspecting the source
[   9.9] Checking for sufficient free disk space in the guest
[   9.9] Converting CentOS release 6.8 (Final) to run on KVM
virt-v2v: error: no installed kernel packages were found.

This probably indicates that virt-v2v was unable to inspect this guest 
properly.

If reporting bugs, run virt-v2v with debugging enabled and include the 
complete output:

  virt-v2v -v -x [...]

This is inspection of old guests, there is no way to modify them.

Setting LEGACY policy in the host isn't going to help.  librpm
is being run inside the libguestfs appliance, not the host.

(In reply to Richard W.M. Jones from comment #8)
> Setting LEGACY policy in the host isn't going to help.  librpm
> is being run inside the libguestfs appliance, not the host.

What builds the appliance? Maybe this step can be tweaked to enable the LEGACY policy?

FWIW, you can work around it with '--nosignature' on the rpm command line (that switch goes back to rpm 4.0 at least)

But this is indeed a nasty change as it suddenly outlaws a significant amount of existing content which is perfectly legit in its creation context. A far less draconian approach would be invalidating only new signatures using obsolete crypto, which would allow eg RHEL 6 content to be verified because the crypto wasn't obsolete at the time of signing but I guess that info is not available to openssl in the relevant context.

I'm starting to think we need to make rpm simply ignore any SHA1 based signatures, ie behave as if it wasn't there at all so such packages appear simply unsigned. Which rpm will then merrily allow, unless enforcing signature checking is enabled, in which case people get the actually desired effect of this all.

(In reply to Florian Weimer from comment #9)
> (In reply to Richard W.M. Jones from comment #8)
> > Setting LEGACY policy in the host isn't going to help.  librpm
> > is being run inside the libguestfs appliance, not the host.
> 
> What builds the appliance? Maybe this step can be tweaked to enable the
> LEGACY policy?

update-crypto-policies needs Python which isn't available inside the appliance.
I guess we could try doing "whatever update-crypto-policies does" (assuming
that is simple and will never change in future) but do we want to downgrade
the security of the whole appliance?  It's used for a variety of things.

(In reply to Panu Matilainen from comment #10)
> FWIW, you can work around it with '--nosignature' on the rpm command line
> (that switch goes back to rpm 4.0 at least)

This might be feasible.  Is there a librpm equivalent of that (we are
calling librpm directly)?  The option parsing code in 'rpm' is hard to follow ...

Seems something like:

rpmtsSetVSFlags(ts, (oflags & ~RPMVSF_MASK_NOSIGNATURES))

(In reply to Richard W.M. Jones from comment #14)
> Seems something like:
> 
> rpmtsSetVSFlags(ts, (oflags & ~RPMVSF_MASK_NOSIGNATURES))

Or rather, the opposite way around.  I'm trying this:

+  /* Disable signature checking (RHBZ#2064182). */
+  oflags = rpmtsVSFlags (ts);
+  rpmtsSetVSFlags (ts, oflags | RPMVSF_MASK_NOSIGNATURES);

Oh, sorry I saw "librpm" mentioned but failed to register. And yes the latter is correct, ie

    rpmtsSetVSFlags(ts, rpmtsFlags(ts)|RPMVSF_MASK_NOSIGNATURES);

OK this seems to work for me:

https://listman.redhat.com/archives/libguestfs/2022-March/028438.html

I think it's worth changing the component now?

Just FWIW, RHEL 6 is signed with RSA/SHA256. Centos may differ.

(In reply to Panu Matilainen from comment #19)
> Just FWIW, RHEL 6 is signed with RSA/SHA256. Centos may differ.

Yes the guest was CentOS 6 (not RHEL).  I just assumed they used the same
signatures, but will change the commit message.  Seems like CentOS RPMs
are here:

https://vault.centos.org/6.0/os/x86_64/Packages/

I grabbed the kernel one and that is signed with RSA/SHA256:

$ rpm -qip kernel-2.6.32-71.el6.x86_64.rpm
warning: kernel-2.6.32-71.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID c105b9de: NOKEY
Name        : kernel
...
Signature   : RSA/SHA256, Sun 03 Jul 2011 05:30:26 BST, Key ID 0946fca2c105b9de

Could the problem not actually be the RPM signatures but something
else in the RPM database of this guest?  I will extract the guest RPM
database and send it to you by email.

> Could the problem not actually be the RPM signatures but something
> else in the RPM database of this guest?  I will extract the guest RPM
> database and send it to you by email.

The log shows a whole bunch of messages like these:
rpmdbNextIterator: skipping h#     440 
Header V3 RSA/SHA1 Signature, key ID c105b9de: BAD

Looking at the db, there are 56 SHA256 signed packages and 240 SHA1 signed packages in it, all by the same key (something like 'rpm --dbpath `pwd` --qf "%{name} %{rsaheader:pgpsig}\n" -qa' on a non-crippled openssl version will show you the details)

It's peculiar as all the SHA256 signatures are from July 2011, and all the *later* signatures are SHA1. I guess somebody has had a moment of "oops" somewhere.

Oh and as for the kernel, which was the original case here:

$ rpm --dbpath `pwd` --qf "%{nevra} %{rsaheader:pgpsig}\n" -q kernel
kernel-2.6.32-431.el6.i686 RSA/SHA1, Sun 24 Nov 2013 09:29:30 PM EET, Key ID 0946fca2c105b9de
kernel-2.6.32-642.1.1.el6.i686 RSA/SHA1, Wed 01 Jun 2016 03:31:15 AM EEST, Key ID 0946fca2c105b9de

Using virt-rescue to chroot into the original system:

$ virt-rescue --ro -a system.vmdk -i

The virt-rescue escape key is ‘^]’.  Type ‘^] h’ for help.

------------------------------------------------------------

Welcome to virt-rescue, the libguestfs rescue shell.

Note: The contents of / (root) are the rescue appliance.
Use 'cd /sysroot' or 'chroot /sysroot' to see guest filesystems.

><rescue> cd /sysroot
><rescue> chroot /sysroot
><rescue> rpm -qi kernel
Name        : kernel                       Relocations: (not relocatable)
Version     : 2.6.32                            Vendor: CentOS
Release     : 431.el6                       Build Date: Fri Nov 22 01:33:16 2013
Install Date: Tue Jun 14 17:42:38 2016         Build Host: c6b8.bsys.dev.centos.org
Group       : System Environment/Kernel     Source RPM: kernel-2.6.32-431.el6.src.rpm
Size        : 92948749                         License: GPLv2
Signature   : RSA/SHA1, Sun Nov 24 19:29:30 2013, Key ID 0946fca2c105b9de
Packager    : CentOS BuildSystem <http://bugs.centos.org>
URL         : http://www.kernel.org/
Summary     : The Linux kernel
Description :
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system.  The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
Name        : kernel                       Relocations: (not relocatable)
Version     : 2.6.32                            Vendor: CentOS
Release     : 642.1.1.el6                   Build Date: Tue May 31 21:02:44 2016
Install Date: Tue Jun 14 17:52:58 2016         Build Host: worker1.bsys.centos.org
Group       : System Environment/Kernel     Source RPM: kernel-2.6.32-642.1.1.el6.src.rpm
Size        : 100365979                        License: GPLv2
Signature   : RSA/SHA1, Wed Jun  1 00:31:15 2016, Key ID 0946fca2c105b9de
Packager    : CentOS BuildSystem <http://bugs.centos.org>
URL         : http://www.kernel.org/
Summary     : The Linux kernel
Description :
The kernel package contains the Linux kernel (vmlinuz), the core of any
Linux operating system.  The kernel handles the basic functions
of the operating system: memory allocation, process allocation, device
input and output, etc.
><rescue>

It looks to me as if this is a genuine CentOS package.  Did we
switch over the SHA256 signatures some time in the middle of the
RHEL or CentOS 6 lifecycle?

Anyway I think the patch above is good.  We don't need to check
signatures in order to inspect packages which are already installed
in the system under inspection.

Worked around in:
https://github.com/libguestfs/libguestfs/commit/aa6f8038f826bfb37ddbbb575e6962e1e181c5e8

This bug is for RHEL 9.0 and requires exception and/or blocker.

I propose for RHEL 9.1 that we pick this up through a regular rebase (bug 2059285)
instead of creating a new bug.

Verified with libguestfs-1.46.1-3.el9_0.x86_64, virt-v2v works fine.

# rpm -q libguestfs
libguestfs-1.46.1-3.el9_0.x86_64

# virt-v2v -i ova centos-Eaton.ova -o null
[   0.0] Setting up the source: -i ova centos-Eaton.ova
virt-v2v: warning: making OVA directory public readable to work around 
libvirt bug https://bugzilla.redhat.com/1045069
virt-v2v: warning: could not parse ovf:Name from OVF document
[   2.7] Opening the source
[   9.3] Inspecting the source
[  12.1] Checking for sufficient free disk space in the guest
[  12.1] Converting CentOS release 6.8 (Final) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  45.4] Mapping filesystem data to avoid copying unused and blank areas
[  46.7] Closing the overlay
[  47.0] Assigning disks to buses
[  47.0] Checking if the guest needs BIOS or UEFI to boot
[  47.0] Setting up the destination: -o null
[  48.0] Copying disk 1/1
█ 100% [****************************************]
[  55.2] Creating output metadata
[  55.2] Finishing off

Build added to the erratum so I believe we are all done here.  If there
is anything missing please let me know.

Besides the CentOS guest, A rhel8 guest was also verified.
And there is no issue.

# avocado run --vt-type v2v convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_verifypeer.preallocated.it_vddk
JOB ID     : 48202f6915481ab63217e95f447a05251db1a79a
JOB LOG    : /root/avocado/job-results/job-2022-03-17T22.44-48202f6/job.log
 (1/1) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_verifypeer.preallocated.it_vddk: STARTED
█ 100% [****************************************]
 (1/1) type_specific.io-github-autotest-libvirt.convert_vm_to_ovirt.esx.vm.7_0.linux.latest8.arch_x86_64.raw_f.NFS.rhv_upload.rhv_direct.rhv_verifypeer.preallocated.it_vddk: PASS (492.31 s)
RESULTS    : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0
JOB TIME   : 493.67 s

So move the bug to VERIFIED.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: libguestfs), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2317