Bug 876423
Summary: | Incorrect X509 Extension parsing results in "TypeError: argument of type 'NoneType' is not iterable" in _is_valid_download_url() | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Update Infrastructure for Cloud Providers | Reporter: | Nigel Jones <nigjones> | ||||
Component: | RHUA | Assignee: | James Slagle <jslagle> | ||||
Status: | CLOSED ERRATA | QA Contact: | mkovacik | ||||
Severity: | high | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 2.1 | CC: | achan, asettle, jmoran, juwu, nigjones, tsanders, vkuznets, whayutin | ||||
Target Milestone: | --- | ||||||
Target Release: | 2.1.1 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
Incorrect parsing logic removed valid data from entitlement certificate's OID values and caused the import of entitlement certificates to fail with traceback errors. This patch prevents the removal of valid data. Certificates now import without issue.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2013-02-27 16:59:59 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: | |||||||
Attachments: |
|
Description
Nigel Jones
2012-11-14 04:26:17 UTC
aligned against our 2.1.1 release patch looks good to me, i can't think of a better way to do it. Thanks for the detailed work debugging this issue. commit cc0c060c832e2f04390196d496690b3e5d1ca07a Hi, I'm not sure about the test automation here; generating a custom certificate in candlepin is outside of the scope for us and keeping the customer certificate as a test case data doesn't seem appropriate either. Any suggestions? Thanks, milan Does the automation test case need to actually verify that the certificate is valid, or just that it will parse correctly? If it doesn't need to be verified, just modify an existing test certificate as this bug describes to exhibit the problem. The certificate won't pass signature validation, but that's not really what needs to be tested here. Other than that, I'm not sure how else to test this via automation. I could probably add a unit test for the __ext method that tests the fix if needed. OK(In reply to comment #5) > Does the automation test case need to actually verify that the certificate > is valid, or just that it will parse correctly? If it doesn't need to be > verified, just modify an existing test certificate as this bug describes to > exhibit the problem. The certificate won't pass signature validation, but > that's not really what needs to be tested here. > > Other than that, I'm not sure how else to test this via automation. I could > probably add a unit test for the __ext method that tests the fix if needed. I'll try to reproduce with a fabricated cert. If it "works" and I get the same stack as in report, no problem automating... Thanks, milan [root@rhua ~]# rpm -q rh-rhui-tools rh-rhui-tools-2.1.15-1.el6_3.noarch [root@rhua ~]# rhui-manager cert upload --cert /root/bug876423_testcert.pem The given certificate contains one or more entitlements that are not compatible with the RHUI. For questions, please visit: https://access.redhat.com/support/contact/customerService.html Created attachment 692849 [details]
Reproducer screen log
Attaching a reproducer (RHUI 2.1)
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, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0571.html |