REQUESTS_DONT_USE_PYOPENSSL

Basically, a lot of people are installing pipenv in envs which also have `requests[security]` installed, which slows down the CLI tool quite a bit (at import time). 

This patch would allow pipenv to disable the upgrade within itself, speeding up the experience for those users. 

/cc @Lukasa @alex 

# [Codecov](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=h1) Report
> Merging [#4273](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=desc) into [master](https://codecov.io/gh/requests/requests/commit/b9638ec7be9134786e28684ca17f3d161297ac5e?src=pr&el=desc) will **increase** coverage by `0.01%`.
> The diff coverage is `n/a`.

[![Impacted file tree graph](https://codecov.io/gh/requests/requests/pull/4273/graphs/tree.svg?width=650&token=mZGswIiXLa&height=150&src=pr)](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=tree)

```diff
@@            Coverage Diff             @@
##           master    #4273      +/-   ##
==========================================
+ Coverage   88.66%   88.68%   +0.01%     
==========================================
  Files          18       18              
  Lines        2021     2023       +2     
==========================================
+ Hits         1792     1794       +2     
  Misses        229      229
```


| [Impacted Files](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=tree) | Coverage Δ | |
|---|---|---|
| [tests/testserver/\_\_init\_\_.py](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=tree#diff-dGVzdHMvdGVzdHNlcnZlci9fX2luaXRfXy5weQ==) | `86.53% <0%> (+0.53%)` | :arrow_up: |

------

[Continue to review full report at Codecov](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=continue).
> **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta)
> `Δ = absolute <relative> (impact)`, `ø = not affected`, `? = missing data`
> Powered by [Codecov](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=footer). Last update [b9638ec...f53f5c2](https://codecov.io/gh/requests/requests/pull/4273?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments).


Ok, so the core problem as I understand it is that the import time of pyopenssl is slow. So I have the following concerns:

1. Can we speed up the import time? This would be ideal if we can.
2. If not, can we be smarter about whether we try to inject into urllib3? If so, that would be good: if we can avoid needing to do this work (e.g. Because the system ssl module is good enough) then we should maybe avoid doing it.
3. If not, then should this hook be a bit more general (e.g. `REQUESTS_SSL_BACKEND` with options including `ssl`, `pyopenssl`, `securetransport`)?

I think feedback on those would be good.

Speeding up import time would be dandy, and make this a non–issue.

I like the backend idea, but I also prefer the currently proposed method, because it's a little more explicit and would be... used less, i think. 

This seems to keep the default behavior, so I'm not super concerned about it. Like @Lukasa , I'd love to understand the root cause of the slowness and see if we can fix it.

Keep in mind that disabling this on Python2.6 and whatever else means they'll see warnings.

Welcome @alex to the team, btw! He's collab on the repo now, as our official security advisor™.

I'm onboard for trying to speed pyopenssl up. I don't particularly like the "set it and forget it" nature of an environment variable for security related features though. I feel like this could be an added source of opened issues for people who forgot they set something.

This would be set by pipenv in the pipenv codebase, before importing requests, and not by a user. It would not effect their environment. 

too bad `__import__` doesn't let you pass arguments to modules. That'd be dope. 

in the meantime, pipenv can monkeypatch requests!

@kennethreitz It would be possible for users to set it though, and we have learned with Requests that users will find and use *every* part of the codebase, documented or not. 

Anyway, I'm ok with adding this too. Let's add it and release early next week, but let's never document it.

Okay so news — did this import get a lot faster recently? I'm trying with latest, and it's super fast on my machine. Users are reporting very slow response though. I think they have older versions. 

It got faster with cryptography 1.0, anything older than that is slow, IIRC.

> It got faster with cryptography 1.0, anything older than that is slow, IIRC.

Right. This is why whenever someone complains that importing requests/pyopenssl is slow I ask for their version of cryptography and suggest they upgrade. I think 1.0 is when a new feature in CFFI was released and Cryptography started taking advantage of it (iirc)

Yeah, that's right.

Also we've fixed several security issues since then, and added support for
newer versions of OpenSSL. I'd suggest `requests[security]` should express
a higher minimum version of pyOpenSSL (though I see it already expresses a
newer minimum version of cryptography, so I don't see how this could happen
on a modern requests).

On Sat, Sep 2, 2017 at 7:49 PM, Ian Stapleton Cordasco <
notifications@github.com> wrote:

> It got faster with cryptography 1.0, anything older than that is slow,
> IIRC.
>
> Right. This is why whenever someone complains that importing
> requests/pyopenssl is slow I ask for their version of cryptography and
> suggest they upgrade. I think 1.0 is when a new feature in CFFI was
> released and Cryptography started taking advantage of it (iirc)
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/requests/requests/pull/4273#issuecomment-326775457>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AAADBNu84mdz7ktNY5Cx06wDGmjfpgGbks5seemngaJpZM4PK__->
> .
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: D1B3 ADC0 E023 8CA6


I still think it would be a nice-to-have — and agreed on never documenting it. 

Hm, so I remembered [this](https://github.com/jakubroztocil/httpie/issues/603) but that's on FreeBSD and should probably be moved over to the cryptography issue tracker.

@sigmavirus24 @nateprewitt The two of you will need to do a review now, because I have added a commit to this branch. :wink:

I'm really not fond of this idea but looks like there's no one else who feels that way.

Well to be clear, as I said earlier in the thread I'm not stoked on the idea either. If we're going to merge this though, I don't see anything technically incorrect here.

@kennethreitz Out of curiosity, would you mind explaining how pipenv would use this? Would you just instruct users to set this? If so, perhaps this may not be worth it. It seems users of pipenv may have better success doing the alternative install that fixed the user's issue https://github.com/kennethreitz/pipenv/issues/465#issuecomment-326769070

@ojek no, pipenv would set this environment variable itself before importing requests. 

it sounds like adding a warning for old versions might be a better idea though

Now that #4332 is merged, are we ok closing this PR, @kennethreitz?