Add SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version bindings

[mhils]

This PR adds the SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version protocol selection mechanisms along with TLS_method/TLS_client_method/TLS_server_method to pyOpenSSL.

depends on pyca/cryptography#5662, fixes #860

[mhils]

This should generally be ready for review, but depends on a new cryptography release (and then a bump of the minimum version here). 😃

[mhils]

Tests for 3.6 and above are passing now. 😃

2.7 and 3.5 are failing because they are not supported by the latest cryptography release anymore. I presume you want to drop them for pyOpenSSL as well soon-ish? :)

[reaperhulk]

We'll try to keep 2.7 support in pyOpenSSL until the minimum version has to be bumped to support new bindings. These bindings were recently added, but were they in the 3.3 release?

[reaperhulk]

I could have scrolled up in this PR. I guess we didn't, which means this requires 3.4? 🤣

[mhils]

• SSL_CTX_set_min_proto_version/SSL_CTX_set_max_proto_version landed in Added tls bindings for new OpenSSL APIs cryptography#5595 on December 1st.
• 3.3 was released on December 8th.
• The version constants landed in Add ssl version constants cryptography#5662 on December 21st.

One could ship a 3.3 release with hardcoded constants if it needs to be, but bumping to 3.4 would be cleaner.

Also - having just taken a quick look at the cryptography tracker - thank you all for the fantastic work! ❤️ All of my projects happily accepted 3.4, everything worked out of the box, and I can't wait to see more memory-safe code being used. :)

[reaperhulk]

Given pyOpenSSL's common use in more legacy environments I think we probably should just hardcode the constants (with comments that state when we move to 3.4+ of cryptography we can switch to getting them from cryptography) and allow the use of 3.3 still. I'd like to keep 2.7 support here another year if possible.

And thanks for the kind words -- it's going to be a rough couple weeks 😄

[reaperhulk]

We dropped py3.5 in 3.3 so you'll need to update the CI config to remove the py35 configs. Sorry about that!

[mhils]

No worries, I was just about to ask if you want me to do it. :)

[reaperhulk]

Also needs a changelog rebase

[mhils]

Turns out the culprit was that constants require single quotes, not double quotes. 🤷‍♂️

Any hints on the py27 job failing with "ERROR: InterpreterNotFound: python2.7"?

[reaperhulk]

Looks like https://github.com/pyca/infra/blob/main/runners/debian/Dockerfile#L20 isn't doing its job. Looking inside the container that's because /etc/debian_version no longer contains a name and instead just has a version number. I wonder how long this has been true...

[reaperhulk]

pyca/infra#340

[mhils]

Ok, removing PIP_NO_BINARY=cryptography in tox.ini fixes the ubuntu-bionic tests:

pyopenssl/tox.ini

Line 19 in d290855

PIP_NO_BINARY=cryptography

PIP_NO_BINARY=:all: was introduced by @hynek in 8b5ee6f ("wheels make testing of various OpenSSLs on OS X impossible") and then changed to only apply to cryptography in 0c21cbd ("Banning all breaks setuptools installation").

Is there a particular (security) reason why cryptography is not installed as a wheel?

If yes, what approach shall we take for the ubuntu-bionic container build? Without wheels, it errors building cryptography.
If no, this PR should be good to go.

[reaperhulk]

I believe this was originally done so we could test alternate versions of OpenSSL against pyOpenSSL rather than just the ones our wheels ship. That seems like it's probably still worthwhile since we don't test that all of pyOpenSSL works on the set of OpenSSL versions cryptography tests against in its own matrix. So we should probably just make it so we can build the rust components in the bionic container.

[mhils]

Alright, this was in fact very straightforward in the end! 😃

[reaperhulk]

Thanks for working through this @mhils

[mhils]

Always welcome, thanks y'all! 😊