You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jan 13, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Jan 13, 2021. It is now read-only.
I'm not sure how much this helps, but I've forked the Python 2.7.6 ssl module as ssl2 and backported NPN support from 3.3. It is likely buggy, but hey, apparently hyper is too :). Let me know if you find it useful; if it gets traction, I'll certainly maintain it, and probably backport more features.
There's a crossover between this and PyOpenSSL. I prefer the interface from the stdlib's ssl module, but PyOpenSSL has the advantage of working on non-CPython interpreters. There's an open PyOpenSSL issue (pyca/pyopenssl#79) that's had some work done so far. I'm honestly not sure which is the better route to go. Thanks for the backport though! (Side note: are you aware of the draft PEP466? Might be worth letting Nick Coghlan know that you've already done some of this work. =) )
I was not aware of PEP466, and let me assure you, it's a big relief. Since the changes to be backported are evidently the entire ssl module modulo a few functions, I doubt my little ssl2 module will be much use (in particular, Python 3.4 hangs the NPN-related functionality off the new SSLContext class, which I imagine will be copied wholesale and then patched up to conform to the 2.x CPython API).
Python 3.5 is still in development, although I'm not sure if the new-feature window is still open; perhaps I'll implement ALPN support therein. In the meantime, I suppose a compatibility layer could be written that exposes PyOpenSSL as a Python 3.4 ssl-like API, along with dependency injection. I'm not sure which way to go either.
I've had this discussion with Nick and Donald, and the basic gist is that adding ALPN in 3.5 won't get it backported to 2.7.
As for supporting 2.7, I'd like to do it, but it requires either a backport of the ssl module (aka PEP 466) or moving to PyOpenSSL (being progressed above). It also requires a bit of a rewrite, I'm depending on some fun 3.3 things.
This is no longer a WIBNI, it's mandatory, because ALPN is mandatory in the spec.
This is a gigantic pain in the ass. Some options:
Wait for OpenSSL to support ALPN. 1.0.2 is in beta and has support, but I have no idea when it's scheduled for release. I'll then need to plumb it through cryptography and PyOpenSSL, which based on prior experience will take a few months. PyOpenSSL will then become mandatory for all currently-supported platforms. This will also require that basically everybody upgrade their copy of OpenSSL, which is going to be really painful on Windows. Maybe I bite the bullet and bundle a copy?
Switch to GnuTLS, which appears to already contain support. I haven't found any Python bindings that support ALPN though, so I'll either have to contribute them myself or create a new set of bindings (who has the time?). I then also require that every platform download and compile the new bindings and have a copy of GnuTLS, making this even more of a pain in the ass than the OpenSSL plan.
I'll then need to plumb it through cryptography and PyOpenSSL, which based on prior experience will take a few months.
We're planning 0.5 to be out in the next week or two so if there's any new bindings you need for ALPN now's a good time to get them in :)
This will also require that basically everybody upgrade their copy of OpenSSL, which is going to be really painful on Windows. Maybe I bite the bullet and bundle a copy?
We are ever so slowly coming round to the idea that maybe we should just statically link (or at least bundle) OpenSSL for Windows in cryptography. Seems a bit mad for you to have to do that upstream and you aren't the first downstream dependency who's faced this issue.
Activity
Lukasa commentedon Mar 20, 2014
Hmm, PyOpenSSL doesn't even support NPN, let alone ALPN. Maybe worth an enhancement?
radix commentedon Mar 26, 2014
I filed this: pyca/pyopenssl#79
Lukasa commentedon Mar 26, 2014
Excellent! Thanks for that! I'll see how hard it's likely to be to implement this in PyOpenSSL. =)
alekstorm commentedon Mar 30, 2014
I'm not sure how much this helps, but I've forked the Python 2.7.6
sslmodule asssl2and backported NPN support from 3.3. It is likely buggy, but hey, apparently hyper is too :). Let me know if you find it useful; if it gets traction, I'll certainly maintain it, and probably backport more features.Lukasa commentedon Mar 30, 2014
There's a crossover between this and PyOpenSSL. I prefer the interface from the stdlib's
sslmodule, but PyOpenSSL has the advantage of working on non-CPython interpreters. There's an open PyOpenSSL issue (pyca/pyopenssl#79) that's had some work done so far. I'm honestly not sure which is the better route to go. Thanks for the backport though! (Side note: are you aware of the draft PEP466? Might be worth letting Nick Coghlan know that you've already done some of this work. =) )alekstorm commentedon Apr 1, 2014
I was not aware of PEP466, and let me assure you, it's a big relief. Since the changes to be backported are evidently the entire
sslmodule modulo a few functions, I doubt my littlessl2module will be much use (in particular, Python 3.4 hangs the NPN-related functionality off the newSSLContextclass, which I imagine will be copied wholesale and then patched up to conform to the 2.x CPython API).Python 3.5 is still in development, although I'm not sure if the new-feature window is still open; perhaps I'll implement ALPN support therein. In the meantime, I suppose a compatibility layer could be written that exposes PyOpenSSL as a Python 3.4
ssl-like API, along with dependency injection. I'm not sure which way to go either.alekstorm commentedon Apr 1, 2014
Ah, I now realize hyper only supports Python 3.3+. What are your feelings on supporting 2.7 as well?
Lukasa commentedon Apr 1, 2014
I've had this discussion with Nick and Donald, and the basic gist is that adding ALPN in 3.5 won't get it backported to 2.7.
As for supporting 2.7, I'd like to do it, but it requires either a backport of the
sslmodule (aka PEP 466) or moving to PyOpenSSL (being progressed above). It also requires a bit of a rewrite, I'm depending on some fun 3.3 things.Lukasa commentedon Jun 5, 2014
This is no longer a WIBNI, it's mandatory, because ALPN is mandatory in the spec.
This is a gigantic pain in the ass. Some options:
What a nightmare.
dimaqq commentedon Jun 5, 2014
+1 for openssl. develop wth beta now, check python mailing list / issues wrt. exposing openssl features to python-land.
public commentedon Jun 5, 2014
We're planning 0.5 to be out in the next week or two so if there's any new bindings you need for ALPN now's a good time to get them in :)
We are ever so slowly coming round to the idea that maybe we should just statically link (or at least bundle) OpenSSL for Windows in cryptography. Seems a bit mad for you to have to do that upstream and you aren't the first downstream dependency who's faced this issue.
Lukasa commentedon Jun 5, 2014
@public What's the position of
cryptographywhen it comes to adding bindings for things that are only in beta OpenSSL?Lukasa commentedon Jun 5, 2014
The other option is NSS, which also appears to have Python bindings.
public commentedon Jun 5, 2014
@Lukasa We test against OpenSSL "1.0.2" https://cryptography.io/en/latest/installation/?highlight=openssl#supported-platforms so I think we'd probably be OK with that.
Lukasa commentedon Feb 21, 2015
This support will be available in Python 3.5 and Python 2.7.10.
Lukasa commentedon Apr 14, 2015
PyOpenSSL is now also unblocked!
Lukasa commentedon Apr 16, 2015
Hurrah, completed!