Botocore: Support for requests>=2.10.0?

[shawnrusaw-wf]

Is there a timeline/plan to sync botocore's vendored requests module to a more recent version? 2.10.0 is able to support making calls from Google App Engine via requests_toolbelt (https://toolbelt.readthedocs.io/en/latest/adapters.html#appengineadapter).

[JordonPhillips]

Upgrading requests is generally a high risk, low reward task. So if we aren't directly benefiting from a new feature or bug fix, it generally isn't worth the risk. However, 2.10 did add the ability to use SOCKS proxies, which is an open feature request.

Even then, we likely won't be able to update past 2.11.1 because they added a feature to attempt to rewind file-like objects on certain kinds of errors, which is something we implemented ourselves some time ago. Balancing those conflicting implementations will be very risky.

[Deewiant]

I just ran into an issue with the outdated requests library. I was wondering why some aws s3 cp invocations were failing with the inscrutable fatal error: [Errno 21] Is a directory. Turns out that having set REQUESTS_CA_BUNDLE=/etc/ca-certificates/extracted/cadir broke botocore because support for setting REQUESTS_CA_BUNDLE to a directory came only in 2.9.0, and botocore is still using 2.7.0 though my installed version of requests is 2.18.1. This was a highly unexpected interaction to me, and it'd be great to get at least this issue fixed.

[kirkhansen]

I've also recently run into the outdated requests library issue, but mine was for the socks5 proxy support I was expecting to work. It'd be great to get it updated to at least 2.10.

[andrey-utkin]

Upgrading requests is generally a high risk, low reward task.

Balancing those conflicting implementations will be very risky.

This is exactly why it is rational to stick with upstream and work on merging your enhancements to upstream codebase :) Vendoring, you have to forward-port your patches yourself routinely anyway and listen to users' moaning about outdated version of vendored dependencies :)

As a person contributing to availability of botocore in Gentoo Linux, I am concerned with it bundling dependencies and not using system-provided packages. This is frowned upon in general as in such case user doesn't have same visibility of obsolete or vulnerable software being installed in their system.

With above rant I intend to gently ask you to consider un-vendoring vendored deps.

[amilstead]

EDIT: I completely missed the original ticket description. Just 👍'ing this.

Throwing my 2 cents in; I have the need for botocore to use later versions of requests as well.

In particular, Google App Engine very much wants to use its own urlfetch implementation for anything HTTP/S related. With botocore having an out of date version of requests, it's not possible to reliably use boto3 in a GAE runtime, since things like the requests-toolbelt monkey patch cannot comply with versions of requests earlier than 2.10.0 (not to mention, the patch has no way of applying itself to botocore's vendored versions of requests).

[Nirvanchik]

In our company builds fail with SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

because of botocore:

[02:21:23]Traceback (most recent call last):
[02:21:23]  File "/tmp/teamcity/buildTmp/tmpk_Jutl.venv/local/lib/python2.7/site-packages/botocore/endpoint.py", line 204, in _get_response
[02:21:23]    proxies=self.proxies, timeout=self.timeout)
[02:21:23]  File "/tmp/teamcity/buildTmp/tmpk_Jutl.venv/local/lib/python2.7/site-packages/botocore/vendored/requests/sessions.py", line 573, in send
[02:21:23]    r = adapter.send(request, **kwargs)
[02:21:23]  File "/tmp/teamcity/buildTmp/tmpk_Jutl.venv/local/lib/python2.7/site-packages/botocore/vendored/requests/adapters.py", line 431, in send
[02:21:23]    raise SSLError(e, request=request)
[02:21:23]SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[02:21:23]DEBUG     Event needs-retry.s3.PutObject: calling handler <botocore.retryhandler.RetryHandler object at 0x7f3270b0dd10>

[Nirvanchik]

github doesn't show full lines, may be now better:

[02:21:23]Traceback (most recent call last):
[02:21:23]  File ".../local/lib/python2.7/site-packages/botocore/endpoint.py", line 204, in _get_response
[02:21:23]    proxies=self.proxies, timeout=self.timeout)
[02:21:23]  File ".../local/lib/python2.7/site-packages/botocore/vendored/requests/sessions.py", line 573, in send
[02:21:23]    r = adapter.send(request, **kwargs)
[02:21:23]  File ".../local/lib/python2.7/site-packages/botocore/vendored/requests/adapters.py", line 431, in send
[02:21:23]    raise SSLError(e, request=request)
[02:21:23]SSLError: [Errno 1] _ssl.c:510: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[02:21:23]DEBUG     Event needs-retry.s3.PutObject: calling handler <botocore.retryhandler.RetryHandler object at 0x7f3270b0dd10>

[jiezhang]

@JordonPhillips Any updates? It would be nice to upgrade requests to support SOCKS proxy. aws cli doesn't accept socks proxy at the moment.

[alangpierce]

It looks like there are two open PRs to unvendor requests and urllib3, which would fix this issue: https://github.com/boto/botocore/pull/1466 https://github.com/boto/botocore/pull/1495

[joguSD]

We have un-vendored requests/urllib3 and are now using urllib3 directly as of botocore v1.11.0.
Relevant upgrade notes.

Does anybody know what work would need to happen to get the ask in the PR working? It seems like upstream urllib3 has some degree of GAE support.

[jamesls]

Following up on this, we are now planning to remove the vendored version of requests. Tracking PR is here: https://github.com/boto/botocore/pull/1829