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.
_python-urllib3_ supports IP addresses in `subjectAltName`
The _python-urllib3_ package, a Python HTTP module with connection pooling and file POST abilities, now supports IP addresses in the `subjectAltName` (SAN) fields.
Description of problem:
Rebase python-requests to v2.12.0+ to provide support for IP Address SAN types.
This is needed for IP-based SAN in HA certificates used by haproxy in Openstack.
I see that the "Version" field of this bug is set to 7.4, but in the RHEL 7.4 Beta python-requests is still at version 2.6.0. Can anyone comment on the likelihood this rebase will happen in time for RHEL 7.4 GA?
Comment 5Charalampos Stratakis
2017-06-01 09:08:09 UTC
(In reply to Carl George from comment #4)
> I see that the "Version" field of this bug is set to 7.4, but in the RHEL
> 7.4 Beta python-requests is still at version 2.6.0. Can anyone comment on
> the likelihood this rebase will happen in time for RHEL 7.4 GA?
Hello Carl,
Unfortunately this fix will not make it for RHEL 7.4 and we are at a point where rebasing python-requests might prove too disruptive, although backporting specific fixes can be considered.
Does your package depend on the support for IP Address SAN types, or something else from the later requests versions?
Thanks for the info Charalampos. I'm working on packaging docker-compose, which has a minimum requirement of 2.6.1 for requests [1]. The commit setting that version [2] makes no mention of why that exact version was needed. That project is a version cautious with minimum/maximum version restrictions, so it's possible that the existing 2.6.0 will work correctly. I'll open an issue upstream to ask, and if there is a specific bug fix they get with 2.6.1 that isn't in 2.6.0, I'll share it and ask for it to be backported.
[1]: https://github.com/docker/compose/blob/1.9.0/setup.py#L34
[2]: https://github.com/docker/compose/commit/d17c4d27fa5259fb8d853ccedc82d28fd199ff8f
Looks like 2.6.0 will be fine for my needs, the bug that was fixed in 2.6.1 was related to vendored libraries, and the RHEL package has all the libraries un-vendored into their own packages.
https://github.com/docker/compose/issues/4884
Comment 10Charalampos Stratakis
2017-07-03 14:19:52 UTC
In RHEL we remove the bundled library of urllib3 and make requests depend on the system installed one. Changing the component to urllib3.
Is that the commit(s) then?
https://github.com/shazow/urllib3/pull/922
It looks like it to me, I just can't confirm that backporting this will make requests handle IP-based SAN because there may be other interdependencies. It is a good place to start though.
Created attachment 1311908[details]
Script to generate certs for mod_ssl
Install the mod_ssl package
copy gencert.sh to /root
Modify it to set the IP address to match the address for your test machine
run gencert.sh as root
This will overwrite files in /etc/pki/tls so do on a system you don't care about
Restart Apache after running
Created attachment 1311909[details]
python script to demonstrate issue
Update the hostname and IP address in the python script to match your environment.
The first request is done to demonstrate that the CA works and is trusted and the SAN in the certificate is valid.
The second request is by IP address and will fail with a traceback because requests doesn't examine IPaddr SAN.
Comment 17Iryna Shcherbina
2017-10-10 12:21:22 UTC
Thanks for the reproducer, Rob. I am now able to reproduce and test the issue, and I do get the traceback:
# python test_script.py
Request hostname OK, code: 403
Requesting IP address, it will fail
Traceback (most recent call last):
...
requests.exceptions.SSLError: hostname '<my_ip_address>' doesn't match either of '<my_hostname>', ' <another_hostname>'
(In reply to Charalampos Stratakis from comment #10)
> Is that the commit(s) then?
>
> https://github.com/shazow/urllib3/pull/922
Seems like backporting this commit should be enough, however we remove the bundled `ssl_match_hostname` library from urllib3, thus will also require updating `python-backports-ssl_match_hostname` to 3.5.0.1. If we do not want to do that update, we can go back to using an updated version bundled by urllib3.
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.
https://access.redhat.com/errata/RHBA-2018:0731