New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ssl broken for python > 2.7.9 #477

Closed
joequant opened this Issue Sep 12, 2014 · 84 comments

Comments

Projects
None yet
@joequant

joequant commented Sep 12, 2014

eventlet/eventlet#135

2.7.9 removed _sslwrap which means that the gevent ssl.py will fail.

@Eugeny

This comment has been minimized.

Show comment
Hide comment
@Eugeny

Eugeny Sep 21, 2014

Contributor

Here's a working polyfill which works with gevent 1.0 + cpython 2.7.9

# Re-add sslwrap to Python 2.7.9
import inspect
__ssl__ = __import__('ssl')

try:
    _ssl = __ssl__._ssl
except AttributeError:
    _ssl = __ssl__._ssl2


def new_sslwrap(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=__ssl__.CERT_NONE, ssl_version=__ssl__.PROTOCOL_SSLv23, ca_certs=None, ciphers=None):
    context = __ssl__.SSLContext(ssl_version)
    context.verify_mode = cert_reqs or __ssl__.CERT_NONE
    if ca_certs:
        context.load_verify_locations(ca_certs)
    if certfile:
        context.load_cert_chain(certfile, keyfile)
    if ciphers:
        context.set_ciphers(ciphers)

    caller_self = inspect.currentframe().f_back.f_locals['self']
    return context._wrap_socket(sock, server_side=server_side, ssl_sock=caller_self)

if not hasattr(_ssl, 'sslwrap'):
    _ssl.sslwrap = new_sslwrap
Contributor

Eugeny commented Sep 21, 2014

Here's a working polyfill which works with gevent 1.0 + cpython 2.7.9

# Re-add sslwrap to Python 2.7.9
import inspect
__ssl__ = __import__('ssl')

try:
    _ssl = __ssl__._ssl
except AttributeError:
    _ssl = __ssl__._ssl2


def new_sslwrap(sock, server_side=False, keyfile=None, certfile=None, cert_reqs=__ssl__.CERT_NONE, ssl_version=__ssl__.PROTOCOL_SSLv23, ca_certs=None, ciphers=None):
    context = __ssl__.SSLContext(ssl_version)
    context.verify_mode = cert_reqs or __ssl__.CERT_NONE
    if ca_certs:
        context.load_verify_locations(ca_certs)
    if certfile:
        context.load_cert_chain(certfile, keyfile)
    if ciphers:
        context.set_ciphers(ciphers)

    caller_self = inspect.currentframe().f_back.f_locals['self']
    return context._wrap_socket(sock, server_side=server_side, ssl_sock=caller_self)

if not hasattr(_ssl, 'sslwrap'):
    _ssl.sslwrap = new_sslwrap

Eugeny added a commit to Eugeny/gevent that referenced this issue Sep 21, 2014

@alexcpsec

This comment has been minimized.

Show comment
Hide comment
@alexcpsec

alexcpsec Nov 6, 2014

Guys, a serious 👍 on this. Amazon issued a mandatory update on their Python 2.7 RPMs that seems to be backporting some of these things from 2.7.9. I can't tell what they updated, but it fails as above.

Took me a long time to trace the issue to this, and to figure out they issued this auto-update directive.

I assume there should be more people coming this way because of this. I'd be very grateful if you can prioritize this.

alexcpsec commented Nov 6, 2014

Guys, a serious 👍 on this. Amazon issued a mandatory update on their Python 2.7 RPMs that seems to be backporting some of these things from 2.7.9. I can't tell what they updated, but it fails as above.

Took me a long time to trace the issue to this, and to figure out they issued this auto-update directive.

I assume there should be more people coming this way because of this. I'd be very grateful if you can prioritize this.

@cbsmith

This comment has been minimized.

Show comment
Hide comment
@cbsmith

cbsmith Nov 7, 2014

LIkewise. I just got hit too. It appears Amazon has backported these to their 2.7 Python RPMs, even though everything claims it is still 2.7.8. SOOO annoying.

cbsmith commented Nov 7, 2014

LIkewise. I just got hit too. It appears Amazon has backported these to their 2.7 Python RPMs, even though everything claims it is still 2.7.8. SOOO annoying.

@denik

This comment has been minimized.

Show comment
Hide comment
@denik

denik Nov 7, 2014

Member

There's some discussion going on python bug tracker whether to restore _sslwrap or not.

Member

denik commented Nov 7, 2014

There's some discussion going on python bug tracker whether to restore _sslwrap or not.

@ellimilial

This comment has been minimized.

Show comment
Hide comment
@ellimilial

ellimilial Nov 7, 2014

This is quite irritating indeed. Digital Ocean Ubuntu Trusty 14.04 is on 2.7.8-1 (which, as @cbsmith mentioned, lacks _sslwrap), ended up forking and applying @Eugeny 's changes to make it work.

ellimilial commented Nov 7, 2014

This is quite irritating indeed. Digital Ocean Ubuntu Trusty 14.04 is on 2.7.8-1 (which, as @cbsmith mentioned, lacks _sslwrap), ended up forking and applying @Eugeny 's changes to make it work.

@alexcpsec

This comment has been minimized.

Show comment
Hide comment
@alexcpsec

alexcpsec Nov 7, 2014

@ellimilial I am not really a Python person, and I could not compile @Eugeny 's changes using cpython as they were. Did you make some adjustments on it to make it work?

alexcpsec commented Nov 7, 2014

@ellimilial I am not really a Python person, and I could not compile @Eugeny 's changes using cpython as they were. Did you make some adjustments on it to make it work?

@ellimilial

This comment has been minimized.

Show comment
Hide comment
@ellimilial

ellimilial Nov 7, 2014

@alexcpsec I forked from yesterday's master and applied the changes, then installed with pip: https://gist.github.com/ellimilial/5ef1d1917e00970d4457

Compiled on fresh Ubuntu 14.04 (python 2.7.8-1), but problems with compiling after installing some oldish python packages (breaking after gevent.corecext.c).

ellimilial commented Nov 7, 2014

@alexcpsec I forked from yesterday's master and applied the changes, then installed with pip: https://gist.github.com/ellimilial/5ef1d1917e00970d4457

Compiled on fresh Ubuntu 14.04 (python 2.7.8-1), but problems with compiling after installing some oldish python packages (breaking after gevent.corecext.c).

@alexcpsec

This comment has been minimized.

Show comment
Hide comment
@alexcpsec

alexcpsec Nov 7, 2014

@ellimilial Thanks! I'll give it a try

alexcpsec commented Nov 7, 2014

@ellimilial Thanks! I'll give it a try

@zappjones

This comment has been minimized.

Show comment
Hide comment
@zappjones

zappjones Nov 14, 2014

This just bit us as well.
Amazon currently says our python version is 2.7.8 but it's most certainly breaking on this.
We applied this patch to ssl.py in gevent and it seems to be working great, thanks :)

zappjones commented Nov 14, 2014

This just bit us as well.
Amazon currently says our python version is 2.7.8 but it's most certainly breaking on this.
We applied this patch to ssl.py in gevent and it seems to be working great, thanks :)

@grubberr

This comment has been minimized.

Show comment
Hide comment
@grubberr

grubberr Nov 24, 2014

the problem already appeared on debian
debian 6 testing python2.7-2.7.8-11
it seems guys from debian already applied that ssl patches

root@server:~# dpkg -l python2.7
ii  python2.7                     2.7.8-11            amd64
root@bots71:~# python -c "import ssl ; ssl._ssl.sslwrap"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'sslwrap'

grubberr commented Nov 24, 2014

the problem already appeared on debian
debian 6 testing python2.7-2.7.8-11
it seems guys from debian already applied that ssl patches

root@server:~# dpkg -l python2.7
ii  python2.7                     2.7.8-11            amd64
root@bots71:~# python -c "import ssl ; ssl._ssl.sslwrap"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
AttributeError: 'module' object has no attribute 'sslwrap'
@asieira

This comment has been minimized.

Show comment
Hide comment
@asieira

asieira commented Dec 12, 2014

+1

@pigmej

This comment has been minimized.

Show comment
Hide comment
@pigmej

pigmej Dec 19, 2014

So the problem is not only with sslwrap being removed.

2.7.9 (and then backported to 2.7.8) added arguments to ssl.SSLSocket.

Old definition was (gevent has still it):
__init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None)

New one is:
__init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None, server_hostname=None, _context=None)

// if someone needs a hack for this, then just add those to constructor and ignore, code will work (but host verification would not)

And as other already mentioned, that "briliant" idea is backported to 2.7.8 on debian/ubuntu, while is't not (yet?) on fedora 21

pigmej commented Dec 19, 2014

So the problem is not only with sslwrap being removed.

2.7.9 (and then backported to 2.7.8) added arguments to ssl.SSLSocket.

Old definition was (gevent has still it):
__init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None)

New one is:
__init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None, server_hostname=None, _context=None)

// if someone needs a hack for this, then just add those to constructor and ignore, code will work (but host verification would not)

And as other already mentioned, that "briliant" idea is backported to 2.7.8 on debian/ubuntu, while is't not (yet?) on fedora 21

@italomaia

This comment has been minimized.

Show comment
Hide comment
@italomaia

italomaia Dec 19, 2014

Eugeny, your snippet fixed things for me. Thanks!
+1

italomaia commented Dec 19, 2014

Eugeny, your snippet fixed things for me. Thanks!
+1

@sailorfred

This comment has been minimized.

Show comment
Hide comment
@sailorfred

sailorfred Dec 23, 2014

This has hit us, too. Do we think there will be a fix soon that doesn't require an application patch that will likely need removing when ssl or gevent or both get updated? I need to set the higher ups' expectations.

sailorfred commented Dec 23, 2014

This has hit us, too. Do we think there will be a fix soon that doesn't require an application patch that will likely need removing when ssl or gevent or both get updated? I need to set the higher ups' expectations.

@mtsgrd

This comment has been minimized.

Show comment
Hide comment
@mtsgrd

mtsgrd Dec 28, 2014

Is this an expected side effect of the issue? I'm on Yosemite 10.10.1 with Python 2.7.9 and I get this error after a gevent monkey patch.

 File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 431, in open
    response = self._open(req, data)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 449, in _open
    '_open', req)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 409, in _call_chain
    result = func(*args)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1240, in https_open
    context=self._context)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1194, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1001, in request
    self._send_request(method, url, body, headers)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1035, in _send_request
    self.endheaders(body)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 997, in endheaders
    self._send_output(message_body)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 850, in _send_output
    self.send(msg)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 812, in send
    self.connect()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1212, in connect
    server_hostname=server_hostname)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 350, in wrap_socket
    _context=self)
TypeError: __init__() got an unexpected keyword argument 'server_hostname'

mtsgrd commented Dec 28, 2014

Is this an expected side effect of the issue? I'm on Yosemite 10.10.1 with Python 2.7.9 and I get this error after a gevent monkey patch.

 File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 431, in open
    response = self._open(req, data)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 449, in _open
    '_open', req)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 409, in _call_chain
    result = func(*args)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1240, in https_open
    context=self._context)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/urllib2.py", line 1194, in do_open
    h.request(req.get_method(), req.get_selector(), req.data, headers)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1001, in request
    self._send_request(method, url, body, headers)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1035, in _send_request
    self.endheaders(body)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 997, in endheaders
    self._send_output(message_body)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 850, in _send_output
    self.send(msg)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 812, in send
    self.connect()
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/httplib.py", line 1212, in connect
    server_hostname=server_hostname)
  File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 350, in wrap_socket
    _context=self)
TypeError: __init__() got an unexpected keyword argument 'server_hostname'
@pigmej

This comment has been minimized.

Show comment
Hide comment
@pigmej

pigmej Dec 28, 2014

@mtsgrd that's exactly what I was talking about. So, yes it's "known".

pigmej commented Dec 28, 2014

@mtsgrd that's exactly what I was talking about. So, yes it's "known".

@mtsgrd

This comment has been minimized.

Show comment
Hide comment
@mtsgrd

mtsgrd Dec 28, 2014

And could someone share their thoughts on side-effects by solving the above this way? mtsgrd@ae03921

edit: I see @pigmej suggests host verification is turned off when modifying the SSLSocket constructor to accept server_hostname and _context.

mtsgrd commented Dec 28, 2014

And could someone share their thoughts on side-effects by solving the above this way? mtsgrd@ae03921

edit: I see @pigmej suggests host verification is turned off when modifying the SSLSocket constructor to accept server_hostname and _context.

@josegonzalez

This comment has been minimized.

Show comment
Hide comment
@josegonzalez

josegonzalez Jan 4, 2015

I had this same issue, but was able to correct it by adding @Eugeny's fix as a custom ssl_279.py module in my app and then importing it. Seems to fix my flask/gevent/gunicorn app at least.

josegonzalez commented Jan 4, 2015

I had this same issue, but was able to correct it by adding @Eugeny's fix as a custom ssl_279.py module in my app and then importing it. Seems to fix my flask/gevent/gunicorn app at least.

@josegonzalez

This comment has been minimized.

Show comment
Hide comment
@josegonzalez

josegonzalez Jan 4, 2015

As @pigmej mentioned, the SSLSocket issue is still a problem. Here's the "bad" code. I looked into the gevent code, don't know what the exact fix would be. Lame that this effects heroku apps :(

josegonzalez commented Jan 4, 2015

As @pigmej mentioned, the SSLSocket issue is still a problem. Here's the "bad" code. I looked into the gevent code, don't know what the exact fix would be. Lame that this effects heroku apps :(

@mtsgrd

This comment has been minimized.

Show comment
Hide comment
@mtsgrd

mtsgrd Jan 8, 2015

@josegonzalez this hasn't affected our Heroku apps in my domain yet. Can you confirm you see it on Heroku?

As of yesterday, I now see this issue on Travis.

mtsgrd commented Jan 8, 2015

@josegonzalez this hasn't affected our Heroku apps in my domain yet. Can you confirm you see it on Heroku?

As of yesterday, I now see this issue on Travis.

@josegonzalez

This comment has been minimized.

Show comment
Hide comment
@josegonzalez

josegonzalez Jan 8, 2015

I definitely saw this on heroku when I commented here last, so I downgraded my python to 2.7.8 to have it work.

josegonzalez commented Jan 8, 2015

I definitely saw this on heroku when I commented here last, so I downgraded my python to 2.7.8 to have it work.

tilgovi added a commit to hypothesis/h that referenced this issue Jan 8, 2015

Add runtime.txt to pin Python version
SSL changes with Python 2.7.9 break SSL under gevent.
gevent/gevent#477
@tomster

This comment has been minimized.

Show comment
Hide comment
@tomster

tomster Jan 19, 2015

@iElectric you sure that patch works? i applied it to gevent 1.0.1 and that results in NameError: global name 'SSLContext' is not defined when running the patched version. looking at the initial file i cannot see how that patch should fix the issue.

does anybody have a fix for this?

tomster commented Jan 19, 2015

@iElectric you sure that patch works? i applied it to gevent 1.0.1 and that results in NameError: global name 'SSLContext' is not defined when running the patched version. looking at the initial file i cannot see how that patch should fix the issue.

does anybody have a fix for this?

@domenkozar

This comment has been minimized.

Show comment
Hide comment
@domenkozar

domenkozar Jan 19, 2015

Could you paste the whole traceback? Thanks!
On 19 Jan 2015 17:13, "Tom Lazar" notifications@github.com wrote:

@iElectric https://github.com/iElectric you sure that patch works? i
applied it to gevent 1.0.1 and that results in NameError: global name
'SSLContext' is not defined when running the patched version. looking at
the initial file i cannot see how that patch should fix the issue.

does anybody have a fix for this?


Reply to this email directly or view it on GitHub
#477 (comment).

domenkozar commented Jan 19, 2015

Could you paste the whole traceback? Thanks!
On 19 Jan 2015 17:13, "Tom Lazar" notifications@github.com wrote:

@iElectric https://github.com/iElectric you sure that patch works? i
applied it to gevent 1.0.1 and that results in NameError: global name
'SSLContext' is not defined when running the patched version. looking at
the initial file i cannot see how that patch should fix the issue.

does anybody have a fix for this?


Reply to this email directly or view it on GitHub
#477 (comment).

@shazow

This comment has been minimized.

Show comment
Hide comment
@shazow

shazow Aug 7, 2015

If one of you would like to submit a claim on Bountysource, I think you can describe the appropriate split and ask them to distribute the bounty accordingly. :) (Might need to send an email once a claim has been submitted.) Let me know if I can help!

shazow commented Aug 7, 2015

If one of you would like to submit a claim on Bountysource, I think you can describe the appropriate split and ask them to distribute the bounty accordingly. :) (Might need to send an email once a claim has been submitted.) Let me know if I can help!

@jasonwiener

This comment has been minimized.

Show comment
Hide comment
@jasonwiener

jasonwiener Sep 20, 2015

Thanks you guys! Really helped me out!

jasonwiener commented Sep 20, 2015

Thanks you guys! Really helped me out!

klondi added a commit to CoresecSystems/combine that referenced this issue Oct 12, 2015

Update to gevent 1.0.2
Using gevent 1.0.1 results in issues when accessing https sources with python 2.7.9:
2015-10-12 20:22:54,826 - combine.reaper - INFO - Fetching inbound URLs
2015-10-12 20:23:00,659 - combine.reaper - ERROR - Request <grequests.AsyncRequest object at 0x3c960746bd0> failed: TypeError("__init__() got an unexpected keyword argument 'server_hostname'",)
2015-10-12 20:23:00,659 - combine.reaper - ERROR - Request <grequests.AsyncRequest object at 0x3c960756490> failed: TypeError("__init__() got an unexpected keyword argument 'server_hostname'",)
2015-10-12 20:23:00,676 - combine.reaper - INFO - Fetching outbound URLs
2015-10-12 20:23:12,284 - combine.reaper - ERROR - Request <grequests.AsyncRequest object at 0x3c960772810> failed: TypeError("__init__() got an unexpected keyword argument 'server_hostname'",)
2015-10-12 20:23:12,284 - combine.reaper - ERROR - Request <grequests.AsyncRequest object at 0x3c95fe63790> failed: TypeError("__init__() got an unexpected keyword argument 'server_hostname'",)
2015-10-12 20:23:12,284 - combine.reaper - ERROR - Request <grequests.AsyncRequest object at 0x3c95fe4add0> failed: TypeError("__init__() got an unexpected keyword argument 'server_hostname'",)
2015-10-12 20:23:12,300 - combine.reaper - INFO - Storing raw feeds in harvest.json

See gevent/gevent#477 for details.
@transfluxus

This comment has been minimized.

Show comment
Hide comment
@transfluxus

transfluxus Nov 3, 2015

I'm using python 2.7.10 and gevent 1.0.1
when I try to upgrade gevent it fails
error: command 'cc' failed with exit status 1

transfluxus commented Nov 3, 2015

I'm using python 2.7.10 and gevent 1.0.1
when I try to upgrade gevent it fails
error: command 'cc' failed with exit status 1

filippog referenced this issue in gwik/geventhttpclient Jul 3, 2016

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 5, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 6, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 7, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 7, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 7, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

guewen added a commit to camptocamp/docker-odoo-project that referenced this issue Jul 7, 2016

Use version 1.0.2 of gevent
To fix error: NameError: name 'PROTOCOL_SSLv3' is not defined

See gevent/gevent#477

goern added a commit to b4mad/sirius that referenced this issue Feb 8, 2017

jbothma added a commit to Code4SA/backchat that referenced this issue Mar 28, 2017

jbothma added a commit to Code4SA/backchat that referenced this issue Mar 28, 2017

hashbrowncipher pushed a commit to hashbrowncipher/gevent that referenced this issue Oct 20, 2018

Ignore basepython for default factors (gevent#477) (gevent#841)
* Add 'ignore_basepython_conflict' option (gevent#477)

tox provides a number of default factors - py27, py34, py35 etc. - that
are tied to particular interpreter versions. It is possible to override
these through individual sections or the global [testenv] section. For
example, consider the following 'tox.ini' file:

  [tox]
  skipsdist = True
  minversion = 2.0
  distribute = False
  envlist = py35,py27,pep8,py34-test

  [testenv]
  basepython = python3
  install_command = pip install {opts} {packages}
  commands =
    python --version

  [testenv:py27]
  basepython = python2.7

Running any target except for 'py27' will result in the same interpreter
being used. On Fedora 28 with the 'python3-tox' package:

  $ tox -qq -e py27
  Python 2.7.15
  $ tox -qq -e py35
  Python 3.6.5
  $ tox -qq -e py34-test
  Python 3.6.5

This is broken by design. Overriding these makes no sense and is a
source of common misconfigurations, as noted in gevent#477. The only sane
thing to do here is ignore the request and use the correct interpreter
or raise a warning. There is merit to both approaches, so this
functionality is exposed by way of a new global configuration option,
'ignore_basepython_conflict'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment