gh-77063: Added support for X25519 in SSLContext.set_ecdh_curve()

[sruester]

bpo-32882: Added support for selecting X25519 in SSLContext.set_ecdh_curve()

https://bugs.python.org/issue32882

• Issue: SSLContext.set_ecdh_curve() not accepting x25519 #77063

[VeNoMouS]

Is this ever going to be implemented? and/or backported to 3.7!?

[sruester]

It is still intended to create a "unified" solution for TLS (https://www.python.org/dev/peps/pep-0543/). IMHO, until then we could well live with the "not unified, but usable" solution.

[VeNoMouS]

I ended up writing my own C API implementation that takes the ssl context ptr address, that way i can just import it as a module

[tiran]

I have replied to you on BPO twenty minutes after you have opened the bug in 2018, https://bugs.python.org/issue32882#msg312408

tl;dr the improve is a good idea in general, but the API should be more generic and not require the user to know curve names. Therefore I proposed to use a list of curve names, preferable from an enum of supported curve names.

[tiran]

See comments on BPO. New APIs should be generic and try to avoid OpenSSL-specific conventions. Let's discuss the new API on BPO first.

PS: I wasn't aware of this PR until your comments pushed it to the top of sort:updated-desc and I just happened to browse the first page. It was created before we had CODEOWNERS assignment fully configured.

[bedevere-bot]

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

[VeNoMouS]

I have replied to you on BPO twenty minutes after you have opened the bug in 2018, https://bugs.python.org/issue32882#msg312408

tl;dr the improve is a good idea in general, but the API should be more generic and not require the user to know curve names. Therefore I proposed to use a list of curve names, preferable from an enum of supported curve names.

I disagree, the user should also have the ability to set curves as they see fit and not be locked down by restrictions like they currently are.

Can't we have both? have a default "preferable" list... but also give the functionality to manipulate OpenSSL with the functionality that is already available in OpensSSL and give power back to the user.

Just my 2 cents.

[tiran]

Please use bugs.python.org for discussions.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[sla-te]

With regards to https://scrapfly.io/blog/how-to-avoid-web-scraping-blocking-tls/, python gets much less interesting for scraping or alike if we are not able to set the curves or ssl extensions ourselves.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.