Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 896657

Summary: SSL handshake errors discarded, troubleshooting rendered impossible
Product: Red Hat Enterprise Linux 6 Reporter: Graham Leggett <minfrin>
Component: python-urlgrabberAssignee: Valentina Mukhamedzhanova <vmukhame>
Status: CLOSED WONTFIX QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: bnater, james.antill, jzeleny, kdudka, mdomonko, packaging-team-maint, tcallawa, tlavigne
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-12-06 10:32:16 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:

Description Graham Leggett 2013-01-17 17:01:32 UTC
When an attempt is make to configure /etc/yum.repos.d/foo.repo using client certificates, the attempt to yum update fails with the following error:

https://[foo]/repomd.xml: [Errno 14] problem making ssl connection

This error message replaces the SSL error, which is discarded.

Searching the source, we find the following code in /usr/lib/python2.6/site-packages/urlgrabber/grabber.py:

            elif errcode == 35:
                msg = _("problem making ssl connection")
                err = URLGrabError(14, msg)
                err.url = self.url
                raise err

What seems to be happening is that curl's error 35 is being replaced by yum's error 14. While curl offers an error details mechanism described at http://curl.haxx.se/libcurl/c/libcurl-errors.html (using the curl_easy_setopt(3) option CURLOPT_ERRORBUFFER), yum ignores this mechanism, reducing all possible SSL error messages to the single error code 14. In the process, SSL problems are impossible to debug and SSL is rendered unusable.

To fix this, yum must query the curl provided API to obtain the SSL error, and then pass that error on to the end user.

Comment 2 RHEL Program Management 2013-01-21 06:47:59 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 Zdeněk Pavlas 2013-04-19 14:19:20 UTC
urlgrabber resets the curl object between requests, and this clears CURLOPT_ERRORBUFFER, so we don't get any more info than errcode == 35.

The error handling could be changed, and we could probably work around the .reset() part by creating new curl object for every request.

--- urlgrabber-3.9.1/urlgrabber/grabber.py.old
+++ urlgrabber-3.9.1/urlgrabber/grabber.py
@@ -1289,7 +1289,7 @@ class PyCurlFileObject():
                 err.url = self.url
                 raise err
             elif errcode == 35:
-                msg = _("problem making ssl connection")
+                msg = _("problem making ssl connection: %s") % e.args[1]
                 err = URLGrabError(14, msg)
                 err.url = self.url
                 raise err
@@ -1353,8 +1353,7 @@ class PyCurlFileObject():
                 raise err
 
     def _do_open(self):
-        self.curl_obj = _curl_cache
-        self.curl_obj.reset() # reset all old settings away, just in case
+        self.curl_obj = pycurl.Curl()
         # setup any ranges
         self._set_opts()
         self._do_grab()

Comment 4 RHEL Program Management 2013-10-14 00:04:24 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 6 Michal Domonkos 2016-11-15 14:43:19 UTC
Originally, this was fixed upstream with:

commit 129e0e9833ad9458acf599f29392214071e1f3b5
Author: Zdenek Pavlas <zpavlas>
Date:   Wed Mar 27 10:43:29 2013 +0100

    curl_obj.reset() is the only way to reset HTTP ranges, revert to it.  BZ 923951

However, we later reverted to resetting curl_obj again because of another bug:

commit 6c07f3ddc58c02a662d3be3133b95a43d5af48b8
Author: Zdenek Pavlas <zpavlas>
Date:   Fri Jan 18 10:57:46 2013 +0100

    URLGrabError(14) cleanup.  BZ 896657
    
    Work around a pycurl bug, so error details are available again.
    Remove all but one code paths that were raising URLGrabError(14),
    and throwing error details away.

Which makes the original commit ineffective.

Comment 7 Michal Domonkos 2016-11-15 14:44:03 UTC
Oops, actually the commits were the other way around :)

Comment 8 Jan Kurik 2017-12-06 10:32:16 UTC
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/