Bug 1778090
| Summary: | RFE: virt-v2v should improve the error message for wrong ca.pem file | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | liuzi <zili> |
| Component: | virt-v2v | Assignee: | Virtualization Maintenance <virt-maint> |
| Status: | CLOSED DUPLICATE | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | unspecified | CC: | fdupont, jsuchane, juzhou, kkiwi, lersek, mxie, mzhan, ptoscano, rjones, tzheng, xiaodwan |
| Target Milestone: | beta | Keywords: | FutureFeature, Reopened, Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | V2V | ||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-04-18 14:50:48 UTC | Type: | Feature Request |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
liuzi
2019-11-29 09:54:23 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. This bug was closed in error by an automated process that we do not control. Reopening. (In reply to liuzi from comment #0) <...snip...> > rhv-verifypeer=true -oo rhv-cafile=/tmp/ca.pem > Traceback (most recent call last): > File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 381, > in authenticate > self._sso_token = self._get_access_token() > File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 617, > in _get_access_token > sso_response = self._get_sso_response(self._sso_url, post_data) > File "/usr/lib64/python3.6/site-packages/ovirtsdk4/__init__.py", line 694, > in _get_sso_response > curl.perform() > pycurl.error: (35, 'error:0609E09C:digital envelope > routines:pkey_set_type:unsupported algorithm') > I'll be honest when saying that I think the treatment of this error looks fine, especially if we consider similar failures on other tools - after all the types/formats of certificates could very well be a factor of the underlying crypto library in use, and I'm not sure we should be trying to parse it, much less give very detailed error messages of why it failed.. In cryptography and authentication, it is pretty common to have an 'all-or-nothing' approach.. So I'll tentatively close this, feel free to reopen. After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. This bug is not stale. It was closed by a process we have no control over. Please ignore the previous comment. This is the first time I'm reading through this bug, and even before reading Klaus's comment 5, I had arrived at the exact same opinion. OpenSSL -- crypto in general -- error messages are *notoriously* varied, there are many factors that can go wrong, especially with OS-level crypto defaults advancing continuously and asynchronously to most applications. The error message is: > pycurl.error: (35, 'error:0609E09C:digital envelope routines:pkey_set_type:unsupported algorithm') First we have the "compressed" OpenSSL error code, 0609E09C, but then pycurl actually decodes that for us with ERR_GET_LIB, ERR_GET_FUNC, ERR_GET_REASON <https://www.openssl.org/docs/man1.1.1/man3/ERR_GET_LIB.html>: - library: digital envelope routines - function: pkey_set_type - reason: unsupported algorithm It's entirely possible that the CA.pem file in this case is *valid*, only the crypto settings on the host where virt-v2v runs (and consequently, where ovirtsdk4 runs) consider the public key algorithm in the certificate *too weak*. How is virt-v2v supposed to explain that? It is an entire OS-level configuration problem, not an application (or even remote hypervisor) problem. ( Just the other day I helped Xueqiang Wei in an offlist thread (msgid <1adccb18-f419-4546-48e2-8f68498ef7fc>) resolve an issue precisely like this, with regard to UEFI HTTPS Boot. The instructions I had provided in <https://bugzilla.redhat.com/show_bug.cgi?id=1906500#c27>, for creating a CA certificate, no longer worked for Xueqiang Wei. Namely, the Certificate Signing Request (CSR) created on a RHEL7 host was now impossible to sign on RHEL9: > Certificate request self-signature did not match the contents > 80FBFB109E7F0000:error:03000098:digital envelope routines:do_sigver_init:invalid digest:crypto/evp/m_sigver.c:333: > 80FBFB109E7F0000:error:06880006:asn1 encoding routines:ASN1_item_verify_ctx:EVP lib:crypto/asn1/a_verify.c:201: Note the reason code: "invalid digest". That was utterly wrong; there was nothing broken with the CSR. Instead, the "genkey" command on the RHEL7 machine used such algorithms for the CSR that the RHEL9 host considered "weak". After running the command > update-crypto-policies --set LEGACY on the RHEL9 host, the same CSR (from RHEL7) could be signed without issues. ) There's an arms' race between RHEL constantly tightening its crypto requirements, and virt-v2v having to connect to less-than-bleeding-edge hypervisors, both on the source side and the destination size. It's a conflict of interest, and whenever things fall apart because of that, end-users may encounter the wildest and most misleading error messages, from deep call stacks in the crypto libs, and we can't do anything about that in virt-v2v. Therefore, I'm now going to close this as a duplicate of bug 2062360 now (even though I'm pretty unconvinced that we should attempt handling this symptom even under bug 2062360; the real issue is bug 2064740!). Thanks. *** This bug has been marked as a duplicate of bug 2062360 *** |