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?
(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?
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 . The commit setting that version  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.
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.
AFAICT support for IPAddress SAN was added when the embedded urllib3 was rebased to 1.19 in commit https://github.com/requests/requests/commit/99fa7becf263473c7bfc1998b41c2c6c80a0f499
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?
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.
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?
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 18.104.22.168. 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.