Update PyOpenSSL dependency.

[Lukasa]

When pyca/pyopenssl#86 is merged and a release is shipped with it, we'll want to update our dependency on PyOpenSSL to get NPN support in our 2.7 and 3.3 versions.

[Lukasa]

We also need DHE/ECDHE support from PyOpenSSL.

[Lukasa]

According to @reaperhulk on Twitter, Cryptography is about a month away from a release, meaning that PyOpenSSL is more than a month away. That's unfortunate for us, as it blocks our release.

[Lukasa]

Other options:

1. Vendor PyOpenSSL and Cryptography using the versions that contain the NPN code.
2. Move the HPACK-6 code into the h2-10 branch, prune it from the development branch and release the development branch alone, without h2-10 support.

[public]

I think we've done point releases to help out downstream before so if it's
just bindings you need we might able to sort something out? I think a month
is probably on the optimistic for 0.4 myself :-)

On 19 April 2014 17:11:24 Cory Benfield notifications@github.com wrote:

According to @reaperhulk on
Twitter,
Cryptography is about a month away from a release, meaning that PyOpenSSL
is more than a month away. That's unfortunate for us, as it blocks our release.

---

Reply to this email directly or view it on GitHub:
#37 (comment)

[Lukasa]

@public I genuinely just need the NPN bindings, assuming that's all that is blocking pyca/pyopenssl#86 (my read is that it is). Is there anything I can do to help make that happen (for example code review, testing etc. etc.)?

[reaperhulk]

It looks like you also want the ECHDE stuff, but I believe we released that in 0.3 and PyOpenSSL just needs a release to support that? We could backport NPN to an 0.3.1 pretty easily so it's mostly a PyOpenSSL question at that point.

[Lukasa]

Yeah, that sounds right to me. =)

I'd like to get this moved forward one step: if we can get a release of cryptography then I can work on getting a release of PyOpenSSL.

[reaperhulk]

Go ahead and file an issue against cryptography requesting a 0.3.1 with pyca/cryptography#857 backported and we can make a decision.

[Lukasa]

Done; see pyca/cryptography#941. @reaperhulk, @public, thanks for your receptiveness! Makes me feel a lot better about adding cryptography as an upstream dependency. =)

[Lukasa]

In case any user is keeping an eye on this issue, I have three outstanding pull requests on PyOpenSSL, of which one blocks release of hyper. This issue blocks because to release without it would be to remove support for Python 3.3, which the current released version has support for.

The relevant issues:

• Next Protocol Negotiation redux pyca/pyopenssl#110 (NPN, blocking)
• Add ALPN support. pyca/pyopenssl#120 (ALPN, non-blocking)
• Implement Connection.recv_into. pyca/pyopenssl#121 (Connection.recv_into, non-blocking)

[dimaqq]

an odd though, should new, beta version of pyOpenSSL be bundled with hyper until it is released if some feature is needed?

[Lukasa]

I thought about it. Don't want to do it yet, but might have to.

[Lukasa]

Again, for those keeping an eye, the blocking issue on PyOpenSSL is pyca/pyopenssl#15.

[Lukasa]

Screw it, I'm not blocking on PyOpenSSL any longer. I'll note that I'm regressing support for Python 3.3, and that we've got partial support for Python 2.7 and PyPy until PyOpenSSL ships a new release.

[Lukasa]

For the moment I'm closing all pyOpenSSL issues, because I simply no longer have faith in the ability of pyopenssl to ship further releases.