Hide Forgot
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? 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
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? 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.
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