Bug 2064182
Summary: | SHA 1 signatures required to inspect packages in RHEL 6 guests | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 9 | Reporter: | Xiaodai Wang <xiaodwan> | |
Component: | libguestfs | Assignee: | Richard W.M. Jones <rjones> | |
Status: | CLOSED ERRATA | QA Contact: | Xiaodai Wang <xiaodwan> | |
Severity: | urgent | Docs Contact: | ||
Priority: | urgent | |||
Version: | 9.0 | CC: | cllang, dbelyavs, fweimer, jen, lersek, marcandre.lureau, pmatilai, pvlasin, rjones, tyan, tzheng, virt-maint, yoguo | |
Target Milestone: | rc | Keywords: | Automation, Triaged | |
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | libguestfs-1.46.1-3.el9_0 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 2065172 2065374 (view as bug list) | Environment: | ||
Last Closed: | 2022-05-17 12:28:38 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 2065172, 2065374 |
Description
Xiaodai Wang
2022-03-15 08:53:12 UTC
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 |