Bug 1124060

Summary: Please build ca-certificates for RHEL5
Product: Red Hat Enterprise Linux 6 Reporter: Erik Johnson <erik>
Component: ca-certificatesAssignee: Kai Engert (:kaie) (inactive account) <kengert>
Status: CLOSED WONTFIX QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.7CC: mitr, tmraz
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-31 13:19:44 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Erik Johnson 2014-07-28 21:50:30 UTC
NOTE: I assigned this to the RHEL 6 product due to it not yet existing for RHEL 5.

I am preparing to submit a review request to EPEL for an EL5 version of the "requests" python module (http://docs.python-requests.org/en/latest/), built against python26. Requests requires the ca-certificates package in order to perform certificate verification. ca-certificates is in base/updates for RHEL6, so I am opening this report for the RHEL product. Please reassign to Fedora EPEL if it belongs there.

If it is moved to EPEL, I'm willing to own and maintain the package for the EL5 branch. My FAS username is terminalmage.

Comment 2 Erik Johnson 2014-07-28 23:13:51 UTC
Note: when trying to mockbuild the CentOS 6 SRPM for epel-5-x86_64, I'm getting keytool errors. An artifact of the difference in openssl versions, perhaps?

% fgrep -A1 -B1 'keytool error' build.log
+ Adding extra-affirmtrustpremiumecc.pem...
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
FAILED
--
+ Adding extra-c2007geotrustincforauthorizeduseonlygeotrustprimarycag2.pem...
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
FAILED
+ Adding extra-c2007thawteincforauthorizeduseonlythawteprimaryrootcag2.pem...
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
FAILED
--
+ Adding extra-comodoeccca.pem...
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
FAILED
--
+ Adding extra-verisigntrustnetworkverisignclass3publicprimarycag4.pem...
keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
FAILED

Comment 3 Kai Engert (:kaie) (inactive account) 2014-07-30 19:15:10 UTC
Erik, do you think we might be able to simple use the files as shipped with the openssl package on RHEL 5?

On RHEL 5, the openssl package contains the CA certificate bundle files.

Do you know which files your python module attempts to access?

Comment 4 Miloslav Trmač 2014-07-30 19:42:31 UTC
(In reply to Kai Engert (:kaie) from comment #3)
> Erik, do you think we might be able to simple use the files as shipped with
> the openssl package on RHEL 5?
> 
> On RHEL 5, the openssl package contains the CA certificate bundle files.

That would probably be the simplest solution; in fact, other RHEL packages in RHEL 5 do directly refer to /etc/pki/tls/certs/ca-bundle.crt in openssl .

As for adding the package to RHEL: RHEL 5, being in a “production 3” lifecycle phase ( https://access.redhat.com/support/policy/updates/errata/ ), is not very likely to add any more packages, and it would require a business justification (so, process-wise, to go through a support request or perhaps an ISV partner contact).

Of course the package could be added to EPEL instead, but that would require extra effort to keep it updated/in sync.


So, if what you are looking for is http://pkgs.fedoraproject.org/cgit/python-requests.git/tree/python-requests-system-cert-bundle.patch , directly depending on openssl and using the path within the openssl package would be by far the simplest way to proceed.

Comment 5 Erik Johnson 2014-07-30 20:02:57 UTC
Good call, I'll try that. Thanks for the suggestion!

Comment 6 Erik Johnson 2014-07-30 22:39:13 UTC
Actually, it looks like it's urllib3 that directly deps on ca-certificates, and urllib3 is a dep of requests. I'll have to check if adjustments will need to be made to the urllib3 el5 spec as well

Comment 7 Erik Johnson 2014-07-31 03:48:48 UTC
Confirmed that both requests and urllib3 needed to be updated with appropriate patches. I was able to get a build of requests that worked using openssl to verify SSL certificates.

Comment 8 Erik Johnson 2014-07-31 03:50:05 UTC
I am unable to close this issue, but it no longer needs to be open.

Comment 9 Miloslav Trmač 2014-07-31 13:19:44 UTC
Thanks for the confirmation, closing.