SSLv3 problem

[csillag]

When trying to launch latest master on my system, I get this:

Error: class uri 'gevent' invalid or not found: 

[Traceback (most recent call last):
  File "<whatever>/h/local/lib/python2.7/site-packages/gunicorn/util.py", line 139, in load_class
    mod = import_module('.'.join(components))
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "<whatever>/h/local/lib/python2.7/site-packages/gunicorn/workers/ggevent.py", line 24, in <module>
    from gevent.server import StreamServer
  File "<whatever>/h/local/lib/python2.7/site-packages/gevent/server.py", line 6, in <module>
    from gevent.socket import EWOULDBLOCK, socket
  File "<whatever>/h/local/lib/python2.7/site-packages/gevent/socket.py", line 659, in <module>
    from gevent.ssl import sslwrap_simple as ssl, SSLError as sslerror, SSLSocket as SSLType
  File "<whatever>/h/local/lib/python2.7/site-packages/gevent/ssl.py", line 386, in <module>
    def get_server_certificate(addr, ssl_version=PROTOCOL_SSLv3, ca_certs=None):
NameError: name 'PROTOCOL_SSLv3' is not defined
]

I guess it's because of the POODLE thingie ...

Can we adapt gunicorn / gevent? (Or has it already been done, and we just need to pick up newer dependencies?)

[csillag]

This is probably the same as Debian bug #770276, reported yesterday.

[csillag]

Btw, as a very temporary workaround (for local environments where SSL is not required or used anyway), changing PROTOCOL_SSLv3 to PROTOCOL_SSLv23 in gevent's ssl.py makes the problem go away.

[tilgovi]

Not a bug in this project.

[csillag]

Not a bug in this project.

Isn't that exactly why we have the Upstream label?

(To track bugs which should be fixed upstream, but we still need to track them, because they impact our project, and we will need to update our dependency requirements eventually?)

[tilgovi]

Which upstream project is there a bug in? Debian is not a dependency of this project.

[csillag]

Which upstream project is there a bug in?

I am guessing gevent, or gunicorn.

[tilgovi]

Gevent is using a constant from the Python standard library that is still defined: https://github.com/python/cpython/blob/08802a11fdb844a5aaec3a1dc67d8281d582d22b/Modules/_ssl.c#L4465

Not only is it defined on the most recent tip of the Python source, it's not even wrapped in a conditional preprocessor macro. It should be always there. So it seems like maybe Debian patched and removed it.

Debian is not a dependency of this project.

[csillag]

So it seems like maybe Debian patched and removed it.

Yes. They did this.

Whether or not it was a prudent decision is debatable, but given the recent problems with SSL3, I think it's reasonable to assume that a significant percentage of distributions will go down that way.

Comparing the global influence of Debian and gevent, I would say that now it's up to gevent to adapt.
(Which, by the way, is not hard.)

So... even if it's not really a bug in gevent, the fix should happen in gevent, which is a dependency of us.

[csillag]

So... even if it's not really a bug in gevent, the fix should happen in gevent, which is a dependency of us.

I have reported the problem to gevent here: gevent/gevent#513
I am adding the Upstream flag, and removing Blocker, because it "only" kills Debian (for now).

[tilgovi]

I can't even find this in Debian. Looking at packages.debian.org (https://packages.debian.org/sid/python) I see:

wheezy: 2.7.3-4+deb7u1
jessie: 2.7.8-2
sid: 2.7.8.2

How did you even get this package (2.7.8-12)?

[csillag]

Check https://packages.debian.org/search?keywords=python2.7 or https://packages.qa.debian.org/p/python2.7.html.
(It's python2.7, not simply python.)

[tilgovi]

Investigating further, the place this is used is get_server_certificate which is gevent's replacement for ssl.get_server_cercificate. That's a public API function, and not used internally anywhere I can find in either the Python standard library, gevent itself, gunicorn, or requests, or urllib3.

In other words, the only reason this affects us at all is that Debian removed a constant that is supposed to be there. As far as I'm concerned that's a ridiculous thing to do. The actual SSL functions can raise errors when given improper values. If they had simply removed the SSLv3 support in their OpenSSL without removing these flags in Python, everything would be fine.

Considering that this change hasn't even made it into wheezy or jessie, I'm going to say that sid is called "unstable" for a reason and this is it. Use it at your own risk.

In this case, I hope they revert this patch. In the meantime, I'm not clogging up this issue tracker with reports about one distributions dubious, compatibility-breaking patch on their unstable line version of Python.

Thanks for reporting it to gevent. I'll go there and add this link, too: http://bugs.python.org/issue20896

Again, we're talking about a constant that's documented as public and still in upstream Python and a distro that removed it only in their unstable release.

[rickhull]

Currently, this constant is also removed in Debian Jessie, the testing-and-very-soon-to-be-stable release, so it's not just Sid/unstable that is impacted. I believe Debian has patched their python-gevent accordingly, but it's still a problem with upstream vanilla python-gevent.

See mistio/mist-ce#434 for more details. Note that I described this as Debian wankery, so I am sympathetic to the closure of this issue.

[csillag]

The problem has been worked around in upstream vanilla gevent, too (see gevent/gevent#517); now we just need a new stable release of gevent.

[rickhull]

Ah, good to know, thanks!